Engineering
Inside Workbench: Our Internal Cloud Agent Workspace
Zichuan Huang, Co-founder & CTO
We built our own internal AI tool, Workbench, to help our team move from a question to a result with fewer handoffs. It gives engineering, product, finance, and BD a shared AI workspace for investigating problems, building and reviewing changes, exploring ideas, and producing reports.
How our teams use Workbench
Engineering: cloud agents in the browser
Workbench’s browser interface gives an engineer a place to work with Codex or Claude Code in the cloud. They can start a task, discuss a plan, follow the agent’s output, and return to code changes and review results in one workspace.
For a change across a backend service and its frontend, for example, the engineer can start from a laptop, let the agent trace the affected repositories, and agree on an implementation plan. The agent can keep working until PRs are ready with approved reviews.
Simple changes from Slack
For a small change with a clear outcome, the request can stay in Slack. On September 7, a 20-page PDF limit was getting in the way of onboarding in both the customer application and the internal admin tool. An engineer tagged Workbench in the product-feedback thread: “remove the 20 page pdf limit from both admin and our frontend.”
About 42 minutes later, Workbench returned two checked and reviewed PRs. The review caught that the first implementation had removed unreadable-PDF validation along with the page limit; the author restored it before approval. Both PRs merged that evening.
Product: answers and interactive prototypes
The same ability to trace code is useful before a change is proposed. Product needs to understand what the application does today and explore how an interaction could work next.
In one Slack thread, a teammate asked whether customers could delete an invoice. Workbench traced the dashboard, GraphQL API, and ledger service. Its answer distinguished issued invoices from recurring invoice templates, which had different capabilities. The recorded run took just over three minutes and surfaced an exception that a quick UI inspection could have missed.
For a proposed payout flow in October, the useful output was an interactive prototype. Workbench built a clickable preview using existing Reah components, covering recipient selection, information requests, review states, and recovery behavior. It identified the unfinished backend connections explicitly. Product and engineering could try the flow, point to specific states, and distinguish interaction decisions from implementation dependencies.
Finance: reports with their methodology
For finance, the output is often a workbook, and the important context is the reporting window, valuation method, and treatment of exceptions.
On October 8, a request in the finance channel asked for a September 30 Treasury balance snapshot in Excel, with seven columns in a specified order. Workbench returned 120 balance rows across 28 entities and 17 logical vaults, plus unallocated Treasury cash with excel attached directly in slack response.
A separate request that morning asked for September conversion and banking revenue by entity, currencies, date, amount, and revenue share. Workbench returned an Excel report and CSV details, documenting reconciliation of 437 fee and cost lines and distinguishing booked revenue, supplier shares, and recorded costs.
BD and customer operations: account status and follow-up
Business development and customer operations use the same access to understand where customers stand and what should happen next.
On October 14, a teammate asked for businesses recently approved for banking across two providers. Workbench returned a CSV in under two minutes, checking approval timestamps, excluding test entities, and handling businesses that appeared under both providers.
The next request in the thread expanded the scope: show completed accounts since an earlier date, alongside businesses waiting on provider review, internal review, or further onboarding work. Workbench returned a workbook and supporting CSVs organized around those stages. That follow-up was a separate run of about ten minutes.
Distinguishing “approved by a provider,” “completed in our product,” and “still waiting on information” helps the team decide whom to follow up with.
Summary
By October 15, Workbench’s retained Slack history included 245 threads in our general help channel and 52 in finance, alongside more than 4,000 engineering-review threads. These counts show the breadth of activity how essential workbench is across the whole company.
How we got here
Codex and Claude Code were part of our daily engineering work at Reah. We wanted to be able to start a task, close the laptop, and return to it later from another computer or a phone. Workbench began as a place in the cloud where those agents could keep working while we stepped away. That sandbox brought together the agent, its repositories, its development tools and shared skills and configurations.
Once that environment existed, the next opportunity was to connect the agent to the systems it was helping us understand. Investigations still involved an engineer copying agent-generated SQL into a database client, running PromQL in a metrics console, inspecting logs, and pasting the results back. Each turn depended on someone moving evidence between tools.
We added database, workflow engine, cloud, and observability access, with the permissions and instructions needed to use them correctly. An agent could now inspect records, trace a failed workflow, and compare the code with runtime behavior inside its own workspace. This made the cloud environment useful for investigating a problem as well as implementing a change.
That access was soon discovered useful beyond engineering. Product, finance, and business development were often asking a developer who just relayed to an agent. Connecting Workbench to Slack shortened that path and freed up engineering bandwidth. Teammates could bring a question and its surrounding conversation directly into a task, then receive an explanation or a file in the same thread.
These additions now share one task system. The technical design makes that environment consistent across entry points and carries the work from the initial question to a result the team can inspect.
Technical design
Supporting these different outputs has led us to a common design. Each request becomes a task with its code, context, tools, and a path for returning the result. Browser sessions, Slack requests, scheduled jobs, and reviews use the same execution infrastructure. Codex and Claude Code provide the agent capabilities; Workbench supplies the environment and the continuity around them.
Shared context, skills, and permissions
Continuity starts with keeping the task’s context beyond any one connection or agent session. Slack tasks capture thread history and supported attachments. Workbench persists decisions, handoffs, and files so a continuation can build on prior work. The banking-report follow-up illustrates why this matters: the team can refine the scope while retaining the context and outputs of the previous investigation.
A skill packages instructions and, where useful, supporting tools. The suite shares a library of these skills and a permission model. The same built-in skills are installed for Codex and Claude Code, and review workspaces receive them even when checking out a single repository. GitHub credentials are brokered for the task, while infrastructure access follows configured identities and resource grants. Skills describe how to investigate; database, cloud, and workflow permissions define what the task can access. Reviewer tasks inspect code and return findings while the author owns the edits.
Maintaining that knowledge centrally lets one investigation improve the next. In July, a Slack request asked Workbench to double-check currencies and decimal representations before reporting financial values. It became a reviewed update to the database skill: distinguish integer smallest-unit amounts from decimal human-unit values, verify the relevant scale, and avoid mixing representations. The corrected instructions then became available to subsequent investigations, reports, and reviews.
The development and review loop
We encode the engineering delivery process in a shared skill called rdev which is the backbone of all our code changes. It tells the author agent how to carry a change from investigation through review and remediation:
Investigate and plan. Read the relevant code and repository conventions, then use live diagnostics when the hypothesis depends on runtime behavior. Compare implementation options and check the plan for missing dependencies, edge cases, verification, and rollout steps. In an interactive task, the user approves the delivery plan before implementation.
Implement and verify. Make the scoped changes, run repository lint and build checks, and run focused tests for the affected behavior. The full test suite runs in CI.
Create or update the PR. Describe the actual change, link the Workbench task, and track the approved plan in a checklist so reviewers can compare the delivery with its intended scope.
Run a separate review task. The
rdev-reviewhelper starts a reviewer against the PR head, using thecode-reviewerskill and repository-specific review rules. It checks correctness, architecture, API compatibility, data access, and failure cases, then returns structured findings with severity and file/line locations. Workbench posts those findings to GitHub.Fix and repeat. MEDIUM, HIGH, and CRITICAL findings block approval. The authoring session addresses them, reruns the relevant focused checks, updates the PR, and requests review again. Subsequent reviews inspect the new changes and recheck unresolved findings against the current code.
Sensitive changes. Changes to schemas, migrations, authentication, credentials, or production infrastructure also receive a focused pass using
sensitive-reviewerskill after the standard review has no blocking findings. The loop ends with a non-blocking review or a specific decision that requires human judgment. The handoff reports CI status separately; review approval does not imply that pending CI has passed or authorize a production release.
Live evidence for planning and review
Readiness also includes access to the systems the agent will investigate. The online skills give author and reviewer tasks a consistent way to collect evidence across those systems, within the permissions available to their task:
Evidence source | Runner access | What it contributes to planning and review |
|---|---|---|
PostgreSQL / AlloyDB | IAM-authenticated database connections through a local proxy; read-only investigation transactions | Actual record states, data shapes, schema assumptions, and currency/unit representations |
Temporal | Read-only workflow, history, schedule, and task-queue inspection | The activity that failed, retries and timeouts, and whether a workflow is waiting, failed, or completed |
GCP and GKE |
and
inspection of permitted resources, configuration, deployment state, and events | Which revision is deployed, whether workers are healthy, and whether an issue depends on configuration or infrastructure |
Application logs | Loki queries using service/environment labels and bounded time windows | Concrete errors and the sequence of events around a transaction or workflow |
Metrics | PromQL against the Prometheus-compatible metrics endpoint |
This access makes the investigation step in rdev more concrete. Before editing, the author can test a hypothesis against real records, correlate an error with a workflow history, and check the deployed service revision. That helps distinguish a code defect from a configuration mismatch, an incomplete rollout, or a failure that has already recovered. A plan can then identify the affected path, the dependencies that must move together, and the evidence needed to verify the fix.
That connects the delivery loop to the system the change will enter. The author plans against runtime conditions, and the reviewer can check both the code and its assumptions about data, configuration, and dependencies. The same access helps a reporting task verify a cohort definition or an operational investigation explain where a workflow stopped.
A real Reah account and a live browser
Workbench also has its own Reah user account. A team can invite that account into the entity it wants to debug, just as it would invite another teammate. The agent can then log in and open that business workspace in its own browser. Entity membership and assigned roles determine what the account can see and do; the debugging task specifies which environment, entity, and behavior to investigate.
The runner includes Playwright and Chromium, so Workbench can reproduce behavior in the live application, inspect rendered states and network responses, and capture screenshots of what it observes. It can connect a visible problem to the corresponding API request, database records, Temporal history, and service logs. That lets an investigation follow a problem from the screen a teammate sees into the systems behind it.
Cronjobs
Recurring work can reuse this foundation through scheduled jobs. We have jobs that inspect production error logs to categorize errors into priority buckets and directly propose reviewed changes to fix them. We also have a daily job to look for completed rollout flag and clean branching logic up. These jobs run on a cron schedule and post results directly to slack where our oncall engineer monitors and merges PRs if needed.
Release Manager
Reah has many microservices and push changes to production every day. It was a nightmare trying to figure out whether a commit is safe to deploy or we’d need to deploy X service first.
Workbench release manager reads cross-repository pins from Go modules, the frontend’s GraphQL schema lock, and the admin application’s protobuf lock. It resolves those pins to commits and compares them with environment markers from GitOps image tags, GCS promotion pointers, and successful Cloud Build deployment runs.
The same view connects the plan to our release workflows. For supported services, an engineer can start a release or hotfix release, or ask a Workbench agent to prepare a hotfix PR from selected commits. Workbench follows the release pipeline to the infrastructure promotion PR and runs its review loop; the engineer merges the reviewed PR and deploys the service.
An engineer can also preview the commits included across the selected release and its dependencies, then share that summary to Slack with links mentioning the authors. This gives the team a common view of what is changing, who owns it, and what needs to happen first.
Workbench began as a way to keep an agent working after engineers closed their laptops and has since quickly evolved into an efficiency tool for the whole company. And of course Workbench researched, consolidated and drafted this article (reviewed and edited by our team).
Share this article
