An AI agent can look underpowered while having access to everything.
It can search messages, documents, calendars, tasks, customer records, and public sources—yet still take too long to answer an ordinary operational question. It calls one tool, reads the result, chooses another, carries a large intermediate payload in context, and repeats. The model spends its time coordinating plumbing the software could have handled directly.
When this happens, teams often blame the model.
The model may not be the bottleneck. The interface between the model and the business may be forcing it to work one pipe fitting at a time.
A tool catalog can become a context tax
Conversational tool calling is valuable. A model receives descriptions of available operations, selects one, supplies arguments, and reasons over the response. For a small number of focused capabilities, the pattern is intuitive and effective.
At operational scale, three costs emerge.
First, tool definitions consume context before useful work begins. A broad catalog may describe hundreds of operations, even though a request needs only a few.
Second, fixed-shape calls expose implementation steps to the model. A request such as “prepare me for this account review” may require separate calls for the account, stakeholders, recent correspondence, open work, approved material, and external signals. The model becomes the workflow engine.
Third, intermediate data passes through the reasoning context. The model may see entire upstream envelopes even when the final answer needs a handful of fields.
The result is not only token cost. It is larger privacy exposure, more opportunities for inconsistent joins, and a workflow that is difficult to reproduce outside the conversation.
Recover a simple idea: programs should compose
The software world solved a similar problem long before language models. Small programs accept inputs, return structured outputs, report failure clearly, and compose into larger workflows.
For agentic systems, a typed command-line capability can be a useful version of that idea. It is not a license to hand the model an unrestricted shell. It is a narrow executable contract around one business domain.
The agent can discover the capability when it needs it, invoke a compound operation, and receive only the selected result. Deterministic steps occur outside the model. The same command can run in a conversation, a scheduled job, a test harness, or a human debugging session.
This pattern is especially strong for compound, recurring, local-first, or auditable work.
The contract matters more than the command line
A machine-ready capability should have six properties.
1. Self-description
The capability publishes a structured catalog of commands, arguments, output fields, permissions, and examples.
The agent does not guess whether the command is search-mail, mail-search, or find. It asks the executable. The catalog can also identify which operations are read-only, which require approval, and which are unavailable in the current environment.
Discovery happens at runtime rather than occupying the context of every turn.
2. A real machine mode
Machine mode should mean structured output, no color, no interactive prompts, stable field names, and typed exit behavior.
Failure must retain meaning. “No matching record,” “ambiguous identity,” “authentication expired,” “permission denied,” and “service unavailable” should not collapse into the same generic error.
A useful capability can say “I do not have a confident match” in a form the orchestrator understands.
3. Source projection
The caller should be able to request only the fields it needs:
account get <id> --select name,status,open_items
Projection at the source reduces context, prevents accidental leakage, and makes downstream behavior more stable. A generic “compact” flag is often too vague; explicit field selection is testable.
4. Compound operations
Repeated multi-call sequences deserve a named operation.
If every account review requires the same five reads and joins, implement account briefing as a read-only compound capability. It can resolve identities, apply deterministic joins, annotate provenance, and return one bounded result.
The model should decide what the evidence means. It should not repeatedly reconstruct the same data pipeline.
5. Out-of-band delivery
Large intermediate results do not need to transit the model.
One capability can write structured output atomically to controlled storage. Deterministic transforms can filter or join it. Another capability can consume the result. The model receives a compact synthesis input or a reference to the artifact.
This changes the privacy and cost profile of complex workflows. The context contains the conclusion and necessary evidence—not every raw record encountered on the way.
6. Retry-safe action semantics
Agents retry, especially after timeouts and partial failures.
Write capabilities need dry-run output, idempotency keys, conflict behavior, and post-action read-back. “Ignore if already satisfied” should be explicit rather than improvised by the model.
The safest retry is one that produces the same business state, not a duplicate message or record.
Local mirrors are an operational feature
For read-heavy work, a synchronized local mirror can make an agent more resilient and easier to audit. Search and joins continue when a remote source is slow. Scheduled workflows do not fail solely because an interactive session expired. The organization can inspect exactly what evidence was available at the time.
Local does not automatically mean current or secure. The mirror still needs encryption, retention rules, identity boundaries, synchronization receipts, and visible freshness. Offline capability is useful only when the system refuses to present yesterday’s cache as today’s fact.
This is not a protocol war
Typed commands and conversational tool protocols solve overlapping but different problems.
Use conversational calls when:
- the capability set is small;
- the interaction is exploratory;
- the model needs to clarify between calls;
- the operation is a focused lookup;
- the host provides strong dynamic tool discovery.
Use composable commands or packaged workflows when:
- the sequence is repeated;
- several calls must be joined;
- intermediate data should stay outside model context;
- the operation must run on a schedule;
- humans need to reproduce it directly;
- local or offline execution matters.
Most useful systems will use both. The design choice belongs at the workflow level, not the ideology level.
Measure sessions, not screenshots
A fast demonstration can conceal an expensive operating pattern. Compare tool approaches across a realistic session.
Measure:
- tool-description context carried across turns;
- number of round trips for the complete job;
- response size before and after projection;
- wall-clock latency including network and process startup;
- effect of caching and deferred discovery;
- sensitive data exposed to the model;
- behavior under expired authentication;
- retry and partial-failure handling;
- reproducibility by a human operator;
- evidence produced after writes.
Expect nuance.
A command process can have startup overhead. Network time may dominate both approaches. A poorly designed command can return more data than a focused function. Modern clients can defer tool schemas and narrow the context gap. Prompt caching can change the economics of a long conversation.
The value of composable plumbing rarely comes from one tiny call. It comes from on-demand discovery, source-side projection, compound operations, and keeping intermediate material outside the reasoning loop.
The workflow should have different clocks
Complex work often combines fast operational reads with slower expert research. Do not force every branch into one synchronous request.
A useful dossier can appear incrementally:
- identity, schedule, and open-work facts arrive quickly;
- document and correspondence synthesis follows;
- deeper research fills in when ready;
- the final merge marks which evidence was present at each stage.
This avoids pretending that every source has the same latency or confidence. The user can act on the fast, verified portion while the slower analysis continues.
Provenance should be a query
The best operational question is often not “what do we know?” but “why did the system say that?”
Every compiled claim should be traceable to its source observations and transformations. A person should be able to select a statement in a briefing and follow it backward: source record, observation time, filter, join, synthesis step.
Provenance should not be a paragraph generated after the fact. It should be part of the data path.
That makes disputes productive. The team can identify whether the source was wrong, stale, misjoined, or misinterpreted.
Build the plumbing around one repeated job
Do not begin by wrapping every company system.
Choose the one job identified for the first AI worker. Trace its reads, deterministic transformations, judgment points, writes, and proof. Build only the capabilities that job requires.
Then ask:
- Which raw reads can be projected?
- Which repeated joins should become a compound operation?
- Which intermediate data can remain outside the model?
- Which action must be idempotent?
- Which source needs a freshness receipt?
- Which result must a human reproduce during an incident?
Good agent plumbing is intentionally boring. It makes the model’s role smaller and more valuable: interpret ambiguity, connect evidence, explain tradeoffs, and make bounded recommendations.
The biggest capability upgrade may not come from a new model. It may come from removing the unnecessary reasoning your current tools force the model to perform.
Pyranthus maps one repeated operation, then assembles the connectors, memory, controls, and working AI workflow needed to carry it. Bring us a workflow.