Code Mode vs MCP: The Case for Taking the Model Out of the Loop

For an agent to interact with the world around it, it has to have tools. An agent needs to be able to:

1. Discover the tools it has available and understand how to use them.
2. Actually use the tool.

MCP dealt with the first part of this very well, but it still left some wondering if the second part can be done better, and even wanting to prove that it can.

The value of an agent comes from having it carry out actions within the various systems that exist outside of it, such as Google Drive, Slack, and Salesforce. Discovering these systems involves a one-off expense, while execution is charged each time work is carried out; this is where the different approaches come into play. The key question is this: how many times must the model be called in order to achieve one unit of work? There are three answers, and the rest of this article examines them in order, from once per action, then once per task, and finally zero times at run time.

The two agent routes, and what they cost

To make the comparison, we're highlighting a real case from inside Orbital Industries.

Within CurieOS, we commonly create and share skills for the whole company to use. A teammate had shipped an internal skill that lets anyone create on-brand artefacts, packaging up styles and assets, so an agent can understand and make use of them appropriately. The skill referenced around sixty image files scattered across Google Drive (logos, flourishes, backgrounds, and so on), along with the scenario each one belongs in. Gathering them into a single shared folder is exactly the kind of tedious job worth handing to an agent, so we ran it twice, once with the agent calling MCP tools and once with the agent writing code.

Through Model Context Protocol, each external system is presented as a collection of named tools which the model can invoke one by one, such as COPY_FILE or SEND_MESSAGE. The agent picks a tool, fills in its arguments, waits, and reads the result before deciding what to do next. It's direct and easy to follow: one call, one action, one result you can inspect.

In CurieOS, Orbital Industries' AI agent, that tool layer was previously provided by Composio, a hosted gateway service that acts as MCP tools for third-party APIs and looks after their OAuth, so the agent can call a tool without having to manage the credentials itself.

When it's applied to about sixty file copies, that approach has a cost. Since each copy involves a separate journey through the model, the agent has to make a tool call, wait, and then the complete result is returned into the context window before the next one begins. Both the latency and the number of tokens used increase as the number of items grows, and the conversation becomes longer as each result builds up behind the others.

Code mode follows a different approach. Instead of invoking a wrapped tool per action, the agent writes and runs a short script that talks to the provider APIs itself. Loops, filtering, and error handling all happen inside one execution rather than across many separate model turns. The model designs the work once; the runtime carries it out.

The authentication that Composio used to handle is now brokered by our WorkOS Pipes integration, which hands short-lived OAuth tokens to the running code.

Applied to the same set of copies, the model writes the loop once and isn't involved again until the task has completed. The iteration happens inside the script, so the whole set costs roughly the same model effort as a single item, and the context stays flat regardless of volume. Errors get caught and handled in code rather than surfacing as separate failed tool calls that the model has to read and react to.

That difference in shape turns up in every dimension we can log. Code mode finished the job in three minutes for cents, against thirteen minutes and dollars for MCP, and it got there on roughly a seventh of the tokens.

In loose terms, this moves the task from O(N) toward O(1).

Measure	Code mode	MCP	Gap
Wall clock	3m 01s	13m 13s	4.4x
Reported cost	$0.xx	$x.xx	3.8x
Total tokens	82.5k	550k	6.7x
Conversation messages	49	207	4.2x
Tool calls	18	92	5.1x

The copy loop is nearly the entire gap: the MCP run made 65 individual copy calls, which accounted for about 150 of its 207 messages, each one paying model latency and returning a payload into context. Code mode did the same copies in a single execution lasting roughly 97 seconds.

Zero duration at run time

Once the model only has to design the work rather than perform it, the next question follows quickly: does it need to be involved at all on the runs after the first?

We've seen the case for this internally with our knowledge graph and workflow engine, where a single change to the graph means updating many other places to keep everything consistent. In a fast-moving company, those agentic workflows quickly add up.

Today, a workflow step that has to reach an external system is usually a CurieOS call: the workflow spins up a full CurieOS agent that reasons about the task and drives it through tools. That's exactly right when the step genuinely needs judgment, but a great many steps don't. "Copy these files into that folder", "post this summary to that channel", "enrich this record from that API": the same deterministic work on every run. Paying for a reasoning agent to re-derive it each time is the workflow-scale version of the per-item round-trip we just measured.

Code mode is what gets us out of that, because if an agent can write a script that does the work once, that script can be promoted to a registered function call that the workflow invokes directly as a deterministic step, with no model in the loop at run time. The agent's role moves from doing the work on every run to now writing, once, the thing that does the work. In this way, a step that used to cost a whole agent invocation becomes a zero-cost function call that behaves identically every time. Beyond that, by observing histories of CurieOS calls, we can compile those down to functions by example.

Authentication makes this safe, since a deterministic function still needs to act on a user's behalf against Google, Slack, or Salesforce, without storing long-lived credentials alongside the code. So when the function runs it gets a short-lived token scoped to user identity, uses it, and discards it. Our agent holds no provider keys of its own, and because the same identity travels end to end, there's no brittle mapping layer between one system's user model and another's.

What changes, and what doesn't

The same tasks finish quicker and for less money, and as these authenticated code paths land in our workflow engine, workflow steps that used to lean on a full agent call can run as compiled functions instead, reducing the cost again on every run.

This doesn't make MCP entirely redundant, though. It still does discovery, which was the part it solved well and which code mode doesn't replace, because an agent has to learn what systems exist and what it can do with them before it can write a line of code against them. It stays the right choice when a step needs a model's judgment on each item rather than the same operation repeated across all of them. And it's the pragmatic option for one-off work, since writing, running, and debugging a script only pays back across volume: there's a crossover point, and for a handful of items it still sits on MCP's side.

Code mode also moves the failure modes around rather than completely removing them. A failed tool call comes back as a legible error the model can read and retry, whereas a bug inside a script can fail quietly or half-succeed, and the model only sees the end state. That's part of the trade you make for keeping the model out of the loop, and it's a large part of why the compiled function step matters: a script that has run correctly many times is a much safer thing to promote than one an agent has just written.

So for repetitive, deterministic work against the major providers, the default shifts: first to code mode, then to compiled equivalents. Everything else connects the way it always has, and custom integrations are still supported.