> ## Content Index
> Fetch the complete content index at: https://blog.ai.gov.sg/llms.txt
> Use this file to discover other available public pages before exploring further.

# ORCA Part 2: Under the Hood
- URL: https://blog.ai.gov.sg/orca-part-2-under-the-hood/
- Published: 2026-07-31T00:00:26.000Z
- Updated: 2026-07-31T07:54:18.000Z
- Description: How ORCA works under the hood: routing each request to the right agent, running generated code in an isolated sandbox, and turning repeat chat tasks into reusable workflows.
- Author: Ethan Mak
- Tags: Agentic, The Studio

# Introduction

In [Part 1](https://blog.ai.gov.sg/orca-one-platform-many-agents-working-together/), we introduced Orchestrated Co-Lab Agents (ORCA), a Whole-of-Government productivity platform that brings multiple AI agents (such as Text Analyst, Data Analyst and Slide Maker) into a single conversational interface, with a leader agent routing each request to the right specialist.

Having covered *what ORCA does* in our first post, we will now dive into *how ORCA works*. We walk through what happens between a user hitting “send” and an answer appearing on screen, and three key design decisions that have shaped the platform: 

1) Running generated code in an isolated sandbox; 

2) Turning repeatable chat tasks into reusable workflows; and 

3) Keeping our own development team aligned with a shared context file.

# How ORCA works

![How ORCA AI works behind the scenes](https://storage.ghost.io/c/ca/f5/caf570e4-5b80-4fc2-b4c8-0c544c2ce19f/content/images/2026/07/data-src-image-614faabf-2ce7-403f-a83a-f0641917d6d5-1.png)

\[How ORCA works behind the scenes\]

**Safety comes first.** Before a message reaches any agent, ORCA runs it through[ Sentinel](https://www.aiguardian.gov.sg/?ref=blog.ai.gov.sg), GovTech's central guardrail service for real-time security and compliance checks, to detect risks like harmful content and prompt-injection attempts. If a message is blocked, ORCA returns a plain-language refusal and the prompt never reaches an agent.

**Next, file preparation.** When a user attaches a 50-page PDF, ORCA uploads it to shared storage rather than the full file into the prompt as this would consume much of the token budget. It only retrieves relevant parts to the task to keep operations lean.

**Then, routing.** By default, the leader agent interprets the user's intent and routes the task to the right specialist. But when users already know which tool they want, a slash command can be used to open Direct Mode (e.g. /slidemaker for the Slide Maker agent), and this skips the leader entirely. This allows ORCA to support users who want the system to coordinate the choice of tools, and those who would rather select the tools themselves.

**Finally, right-sizing the model.** ORCA avoids using large frontier models for work that does not require them. Routine tasks such as batch-labelling CSV rows, checking for headers, or drafting long reports in sections are delegated to cheaper, faster models. 

# Isolated Sandbox: running code off the main server

Users get the most value when agents can act on a file, to perform tasks like calculating figures, generating charts, and cleaning spreadsheets. To analyse a spreadsheet, the Data Analyst agent may load the data with the *pandas* library, reshape the fields, fit a simple model, and produce a chart with a brief report. This is work that is clearly suited for Python, not pure text generation, because small calculations can be costly.

Running generated code inside the main backend may work in a demo, however it ties application stability to runtime-generated scripts.

To avoid this, generated code runs in a dedicated execution service defined by two properties:

- **Isolation.** A runaway script cannot reach the orchestration process, the database, or platform files. If code fails, runs too long, or exhausts its resources, the failure is contained within the sandbox.
- **Ephemerality.** Each unit of work runs in a clean environment, returns its result, and leaves no residual state. Warm environments would make repeated runs faster, but would risk one user’s data persisting into another run. Trading the former for the latter is unacceptable on a government platform.

The sandbox follows the same file-reference pattern as the rest of ORCA: code reads its input from shared storage and writes output back to storage, returning a file reference to the agent. Large data stays out of the model context, and other agents can retrieve the artefact later using the same path.

![Generated code is executed in an isolated, ephemeral sandbox, away from the main server](https://storage.ghost.io/c/ca/f5/caf570e4-5b80-4fc2-b4c8-0c544c2ce19f/content/images/2026/07/data-src-image-ad626851-dd27-4d96-bb36-1f274bbf131c.png)

Generated code is executed in an isolated, ephemeral sandbox, away from the main server

The sandbox image itself manages a carefully engineered balance: too narrow, and code fails on missing dependencies; too broad, and cold starts slow. ORCA uses a base image covering common data-analysis work and adds dependencies only when recurring tasks show they are needed. The sandbox is scoped to interactive computation that completes within one turn. Anything larger, such as model training or very large datasets, belongs in a separate, more appropriate service.

# Workflow Builder: from running the work to building the tool

Chat is great for shaping work while the user is still figuring things out. But once a task becomes fixed, chat adds friction. Instead of typing the same instruction to repeat the same task, we introduced Workflow Builder for users to convert a chat-based process into a repeatable tool.

Consider a monthly task requiring users to process a CSV file with customer feedback. The Text Analyst agent can classify each row and return a labelled file with a summary. With Workflow Builder, the user turns that capability into a workflow shaped around their own file format, categories, and review steps:

*"Create a workflow that reads my monthly feedback CSV, labels each row using the categories I provide, and gives me a classified CSV plus a short distribution report."*

ORCA turns that sentence into concrete steps: confirm the file, sample the data, classify the full file, and produce a summary. The classification engine does the same core work; the scaffolding changes. The process is now explicit, reusable, and also editable. If the categories change next month, the user can edit the workflow directly instead of filing a feature request.

![[Turning natural language into structured workflow]](https://storage.ghost.io/c/ca/f5/caf570e4-5b80-4fc2-b4c8-0c544c2ce19f/content/images/2026/07/data-src-image-18ae9f87-b9fc-4fbb-9c47-72eaf5d2b4a2.png)

\[Turning natural language into structured workflow\]

Under the hood, workflow creation is based on structure, not a single large prompt. ORCA generates a structured document defining the required inputs, ordered phases, and the agent, tool, or transform assigned to each step. Before the workflow can be saved, ORCA validates it: referenced inputs must exist, declared inputs must be used, each step must call a valid agent or tool, and the draft must show no signs of resource abuse or injected instructions. The explicit structure makes the workflow repeatable and auditable, even if the generated text varies slightly between runs.

Two design choices keep this grounded. First, Workflow Builder uses the same agents and tools available in chat, allowing users to explore a task conversationally, then reuse the same capabilities in a structured workflow. Second, it targets the gap between one-off chats and dedicated apps, where tasks are too repetitive to do manually, but too small, variable, or team-specific to justify a full vendor build.

![[Tender evaluation and CSV classifier described once, now ready to run again]](https://storage.ghost.io/c/ca/f5/caf570e4-5b80-4fc2-b4c8-0c544c2ce19f/content/images/2026/07/Screenshot-2026-07-30-at-10.37.31---AM.png)

\[Tender evaluation and CSV classifier described once, now ready to run again\]

ORCA’s Workflow Builder can potentially generate significant value for users, but is still maturing. Sometimes it produces a useful workflow on the first attempt, at times the user must adjust steps or clarify inputs first. Repeatability also carries its own risk: a poorly designed workflow reproduces poor results. The goal is not to automate every prompt, but to turn well-defined tasks into workflows reliable enough to reuse.

# Shared Context: one file the whole team builds from

Underlying how ORCA works is another consideration: how the team builds and maintains it. AI-assisted development has become normal engineering practice, and we use assistants daily to draft, refactor, and explain code. But an assistant is only as good as the context. On a large codebase, it may understand the file in front of it while missing finer, but no less important, aspects of the wider system, such as an existing helper in another module, a convention agreed upon months ago, or an implicit step that every new feature should follow. The output can look correct in isolation and still drift from how the system is meant to work.

We saw this as ORCA grew as a product and platform. Similar logic appeared in multiple places, implemented slightly differently, because each developer's assistant worked from a limited view or memory, whilst missing conventions that were not explicitly articulated. The system still ran but technical debt accumulated through duplicated code, inconsistent patterns, and a codebase that became less intuitive over time.

The fix was to keep a single context file with the codebase, not with any individual developer, and require every assistant to read it before making changes. The file does not describe the entire system and instead points to sources of truth (wiki, architecture notes, runbooks), conventions that apply across the codebase, and critical steps.

A shared context file is only useful if it stays accurate. A convention removed from practice but still documented as mandatory is worse than missing context: the assistant keeps enforcing a rule the team has abandoned, and because every assistant reads the same file, the drift misleads the whole team at once. The file therefore needs clear ownership, regular review, and the same maintenance discipline as the code it describes. Formatting and naming the file - whether as CLAUDE.MD, or AGENTS.MD, or something else - is the easy part. The harder work is deciding what belongs in it, assigning ownership, and keeping it accurate as the system grows.

# Conclusion and what’s next

Beyond what ORCA looks like to its user, and what keeps it running under the hood, a platform like this also has to be affordable to run. In Part 3 of this series, we will look at the costs of operating ORCA, including how techniques such as caching keep token spend under control without compromising user experience.

ORCA is still evolving. Our internal catalogue of agents continues to grow as we collaborate with more teams to connect specialised tools to ORCA. If you have a tool for government officers that is available via API, MCP, or A2A, we would like to hear from you. You bring the tool. ORCA brings the reach.

**If you’re on the Government Enterprise Network, give ORCA a go at:** [**go.gov.sg/orca**](http://go.gov.sg/orca?ref=blog.ai.gov.sg)

# Credits

ORCA is a team effort. The core engineering team comprises GovTech engineers Ethan Mak (lead), Dr. Joel Koo, Shaun Ang, and MOM engineer Dr. Winston Pang. Notably, the Slide Maker agent was developed by Dr. Winston Pang and the Data Analyst agent by our intern Chia Ren Cong.

Building the platform is only half the job. Annalyn Ng, our product manager, guided ORCA from conception to launch and beyond, Jasmine Chua, our chief engagement officer, brings users on board and keeps them coming back, while Esther Lim, our creative director, oversees ORCA's design spanning its UI/UX to promotional fliers.

Finally, ORCA would not have been possible without the steadfast support of MOM's leadership team: Eu Gene Ng, Deputy Director of Co-Lab, as well as Jeremy Huang, former Director, and Leong Wei Jian, current Director of the Strategic Planning and Transformation Department.