Never let your agent choose its own tool

Prompt One argues that enterprise workflow agents should never choose their own tools at runtime, advocating instead for a compiled workflow agent architecture in which the LLM selects and validates commands at design time under the author's identity. The company cites Anthropic's engineering team finding that an agent connected to thousands of tools processes hundreds of thousands of tokens before it reads the request, and points to prompt injection as a top risk for LLM applications under the Model Context Protocol (MCP) approach. Prompt One says it built its Service CLI to serve this design-time and runtime role, with the Composer generating and validating agent code in a loop with the CLI.

For an AI agent, security and governance begin with its design and implementation, long before it is deployed and run. A runtime-reasoning agent one based on a skill or a prompt's instructions relies on the model to decide which tool to call and with which arguments. A compiled workflow agent , the architecture we described in an earlier post /blog/enterprise-agents-compiled/ , uses the LLM as its compiler: it makes those decisions at design time, where they are validated for scope and authorization under the author's identity. Design-time security is the essence of security by construction. Most agents that automate enterprise workflows run a defined process: on a schedule, or on every new record or update. Those agents should never choose their own tools. Unlike an ad-hoc or exploratory research agent, a workflow agent should have its commands chosen, validated, and fixed at design time. This is the first of two posts that follow a compiled workflow agent's access to your systems of record. Part one is agent code generation: how the Composer writes and validates the agent's code, and every command in it, in a loop with the Prompt One Service CLI . Part two describes agent execution and what the gateway does with those commands when the agent runs. A tool that describes itself The Model Context Protocol MCP puts a protocol server between an agent and a SaaS API, and sends the agent a list of tools to choose from on every turn. A runtime-reasoning agent built this way incurs three separate costs. The first is paid in tokens. Every tool definition occupies context before any work begins; Anthropic's engineering team reports https://www.anthropic.com/engineering/code-execution-with-mcp that an agent connected to thousands of tools processes hundreds of thousands of tokens before it reads the request. The second is response variability. The model chooses which tool to call, with which arguments, at runtime, so the same job can take a different path today than it took yesterday. The third is exposure at execution. The agent holds a live credential for each system, and an MCP tool returns whatever the API returns with no filtering in between. That leaves the agent open to prompt injection, a top risk https://genai.owasp.org/llm-top-10/ for LLM applications. The model reads everything it retrieves as part of its own context, so instructions hidden in an email, a ticket comment, or a record field can redirect its next tool call, and that call runs with the agent's full permissions. Consider the alternative: one command-line tool that covers every endpoint of every API an enterprise runs, with the same grammar and semantics for all of them. Its commands describe themselves when asked, with their schema, worked examples, and the structure of their output. Every command declares what it is safe to do before it runs. Every error explains itself in a form the agent can act on. It addresses records by canonical name, so an account in the CRM and the same account in the service desk share one name across every endpoint. APIs can support this. Every serious SaaS API publishes a machine-readable specification of itself, and a command line can introspect that specification without a server process, a protocol handshake, or a tool list re-sent on every turn. Today's AI code-generation capabilities make it practical to build and maintain a provider for every API an enterprise needs, each generated from that API's own specification, including deployment-specific customizations. Security by construction requires such a tool, which is why Prompt One built its Service CLI. The Service CLI has a critical role at both design time and runtime. At design time, it is how the Composer learns what is possible and what authorizations are required. While constructing a Motion, the Composer asks the CLI which providers exist, what each command does, what its results look like, then composes the exact commands the agent will run. At runtime, those same commands execute through the CLI, running inside the Prompt One gateway, which supplies the credentials and enforces policy on every call. Design-time discovery loop When a user describes their motion, the Composer generates the agent's code, and for each API access, it works through a fixed discovery cycle with the Service CLI: discover providers, get the canonical schema, get examples and structure, and finally compose the query.<sup 1 note-1 </sup The result is a validated, deterministic command baked into the agent's code for every system the motion accesses. 1. Discover. Which providers exist, what each one holds, and every real command it exposes, so the Composer chooses a command that exists. Discovery reads the tenant under the author's identity: custom objects and fields, picklist values, and permissions are read and held in the gateway, and the Composer sees only the objects and fields the author is entitled to. It cannot generate a query the author could not run. That is security by construction applied to authoring: an unauthorized query cannot be written, let alone compiled. 2. Introspect. The chosen command's flags, worked examples, and response structure, so the query is composed from the real schema. 3. Generate. The exact command, with its flags, goes into the generated code. 4. Validate. The gateway runs the command as a sample preview before the Motion is committed. If validation fails, the loop continues: the error names the rule that was broken and includes a command that works, and the Composer returns to discovery with that correction in hand. The loop exits only when the command runs clean. The acting user's identity is injected by the engine at execution. The generated code has no access to it, so the Composer cannot write an agent that acts as someone else. The result is a Motion : a versioned definition containing exact commands, fixed for every run. What each run costs, compared with MCP Take a renewal motion, for example: every morning, find the opportunities closing in the next ninety days, check whether any of those accounts have an open priority-one incident in the service desk, and flag the renewals at risk. Two systems, two queries, one join, and a judgment call at the end. Built as a runtime-reasoning agent over MCP, the motion starts every morning the same way. The Salesforce and ServiceNow tool definitions load into context, the model reads them, decides which tool to call and with what arguments, and calls it. The raw result comes back into context. The model reasons about the second call, makes it, and reasons about the join. If it picked the wrong field name for the account or hit a permission it did not have, it reads the error, adjusts, and tries again. Every one of those steps has an inference cost, the path can differ from yesterday's, and the whole sequence repeats tomorrow whether or not anything changed. Built as a compiled workflow agent, it simply executes the two CLI commands the Composer wrote into the Motion every morning and joins the results on the account's canonical name.<sup 2 note-2 </sup No model is involved: no tool definitions loaded, no reasoning about which call to make, no interpretation of the results, no retries. The only model call in the whole run is the bounded judgment at the end, and a motion with no judgment step makes none at all. On a morning with no new opportunities, it is zero tokens. The difference compounds with cadence. A runtime agent pays its reasoning cost on every execution, so the bill grows with the number of runs whether or not anything changed. A compiled agent pays once at design time, and a hundred runs a day cost the same tokens as one. Anthropic's engineering team reports https://www.anthropic.com/engineering/code-execution-with-mcp that replacing direct tool calls with generated code cut one workflow from 150,000 tokens to 2,000, a 98.7 percent reduction. Cloudflare demonstrates the same result https://blog.cloudflare.com/code-mode-mcp/ with what it calls Code Mode, presenting an API of more than 2,500 endpoints to an agent in roughly 1,000 tokens. That is compelling evidence for compiled workflow agents: even the strongest form of runtime tool selection, measured by its own advocates, shows the advantages of compiled code. In both runtime examples, the model generates code every time the task is run; the code executes to make the API calls and filter the results, so only a small payload returns to the model's context. The saving comes from keeping the data out of context. The cost paid is generating the program, every time the agent runs. A compiled workflow agent pays it just once. The Composer writes those exact CLI commands at design time, and the agent executes them as often as necessary, with zero inference cost. On a fixed cadence that is the whole difference: one inference loop per run, or none. In our own measured comparison /resources/agent-framework/ sec-cost-detail , with the same resume-screening agent built both ways, the compiled version consumed about one-fifth the input tokens per run 10,383 versus 52,646 and roughly one-eleventh the cost. Justin Poehnelt's essay on the MCP abstraction tax https://justin.poehnelt.com/posts/mcp-abstraction-tax/ explains why: every protocol layer between an agent and an API loses fidelity, and that loss is paid for on every turn. Why a Service CLI The objective of the Service CLI is to make security by construction possible: every command an agent runs is written only once, under the author's own identity, and validated for scope. That requires a tool that covers every endpoint, describes itself on request, declares what each command is safe to do, and answers in canonical names across systems, so the Composer can learn what it needs at design time and leave nothing for a model to decide at runtime. The cost advantage follows as a consequence: because those commands run as code, the agent consumes no tokens for tool definitions, reasoning, or retries on any run. Part two follows those commands into production. When the agent runs, every one of them passes through the gateway, which forwards the acting user's identity, holds the credentials, checks scope, fields, query constraints, and blast radius before anything reaches a SaaS API. In the meantime, the whitepaper Enterprise Agents, Compiled /resources/downloads/?doc=enterprise-agents-compiled covers the full lifecycle, and if your team has a motion it wants compiled, start a free trial /trial/ and watch the loop run on your own systems. 1. The discovery cycle is documented in our whitepaper Inside a Compiled Workflow Agent /resources/downloads/?doc=inside-prompt-one , in the section on the Service CLI. 2. How the gateway resolves a canonical name to each system's native objects and fields on every call is covered in an upcomming part two.