The Myth of the System Prompt

Many engineering teams treat context as a simple text string appended to a prompt. This is a catastrophic oversimplification. True context is a structural engineering problem. It requires continuous, bidirectional flow between an isolated autonomous agent and the chaotic reality of enterprise data.

Think about what a system prompt actually is. Somebody sat down on a particular afternoon and wrote a few paragraphs describing what they guessed the agent would need to know. Then it shipped. From that moment it started going stale, because the business kept moving and the paragraph did not. The price changed. A permission was revoked. The budget for the quarter ran out on a Thursday. The agent that acts on Friday is still working from the afternoon the prompt was written, and it has no way to know that.

A chatbot can get away with that. Software that acts on stale context is a liability.

If an agent decides to reroute inventory, rewrite a production database, or execute a trade, a simple log file is insufficient. The underlying infrastructure must cryptographically prove exactly what data the agent saw, who authorized the boundary, and what the financial impact will be before the action executes. Context is the strict boundary condition for autonomous action.

Where context actually comes from

A paragraph of text has one source, the person who wrote it. Working context has three, and they move at different speeds.

The first is your own environment. Architecture, constraints, dependencies, the real shape of the codebases and systems the agent is about to touch. This changes every time someone merges a branch. The second is the outside world, which does not care about your release schedule: new tools, new vulnerabilities, a supplier that went dark overnight. Each source worth caring about needs its own feed, structured and scored, because an agent cannot weigh what it cannot compare.

The third is the one teams forget, and it is the agent’s own activity. Everything the system did yesterday is evidence about what it should do today. What it tried and what that cost. If that record evaporates when the session ends, every task starts from zero and you pay for the same lesson twice. Then a third time.

None of these fits in a string. All of them have to be collected, signed, and served at the moment of decision. That is the work we organize Ultimus around.

Engineering Contextual Reality

Serving context to an autonomous system requires managing four distinct operational pillars simultaneously. You cannot build a reliable agentic workflow without satisfying every single one.

Pillar	The Contextual Requirement	The Enterprise Value
Efficiency	Real-time tracking of compute, carbon, and dollar costs per action.	Prevents rogue agentic spend and resource drain.
Safety	Cryptographic verification of permitted actions and data access.	Ensures strict compliance and network security.
Reliability	Rigid testing of outputs against operational baselines.	Eliminates drift in mission-critical workflows.
Utility	Direct alignment of agent execution to defined business outcomes.	Guarantees the automated work drives measurable ROI.

It is tempting to read that table as four features and start ranking them. Resist it. They are four views of the same action, and an action that passes three of them is still a bad action. Work that is safe, reliable and cheap, and moves no outcome anyone cares about, is just a tidy way to burn money.

What the numbers did to our own story

We learned the efficiency pillar the uncomfortable way, on ourselves.

We instrumented our own harness across 61 real working sessions and ran the token counts against real price tables. The headline was large: Ultimus, running an open-weight model, cost about 110 times less per 1,000 output tokens than Claude Code on Opus 5. We had a story ready for that number. The story was that our loop was smarter. Better compaction and pruning, a tighter context window.

The telemetry disagreed. Force both sides onto the same scale and the harness accounted for roughly 1.2 times. Almost all of the gap came from the model we chose to run. The machinery we were proudest of barely registered.

That is an awkward thing to find out, and it is exactly why you measure. Without the record we would have told customers the wrong story with total confidence, and some of them would have made budget decisions on it. The full breakdown, including what it does not prove, is on the benchmark page.

The Two-Way Street of Telemetry

The true complexity of context lies in its dual audience. The infrastructure must serve reality in two directions at once. It must feed the agent the structured ground truth required to act accurately. At the exact same time, it must feed human operators the financial, environmental, and security telemetry required to govern those actions.

These are the same numbers, read by two different readers. An agent reads the cost record and chooses a cheaper path or a lighter model on the next step. A person reads it and changes a workflow or a budget. When the two readers see different numbers, they drift apart, and drift between a machine and the people accountable for it is how incidents start.

And people do more than read. They review, and then they ratify. That second verb carries weight. A report that nobody has to sign is a newsletter. A record that a named person approved, against a boundary that was signed before the action ran, is something you can hand to an auditor or a commander.

A system whose decisions no human can audit is uncontrolled. We have been calling that autonomy. Capability that no one can verify is useless in an enterprise environment.

Software used to retrieve information. Now it takes independent action on behalf of global enterprises and defense operations. Securing that future requires building the heavy infrastructure that forces every automated decision to check in with reality. We must engineer the context for responsible autonomy, providing absolute ground truth for everything that acts.