During this time, we've also introduced skills, plugins, marketplaces, agents and so many different ways of organizing knowledge. This is great. every one of these innovations has helped us build towards the next step in our AI journey.

But increasingly, I'm seeing a different conversation happening inside companies. It's no longer "what's the next big thing we're missing?" but rather, "what do we do with all this stuff?"

I recently ran an internal audit at my workplace. Nearly 6,000 skills spread across thousands of marketplaces and repositories. I categorized every single skill. And what did I discover?

The ten largest capability categories accounted for 2,444 unique skill locations. That's 45.57%.

The top 20 accounted for 3,508 unique skill locations. That's 65.41%.

Think about that. Just 20 broad categories of capabilities account for nearly two-thirds of our entire skills landscape.

That doesn't mean they're all doing exactly the same thing. But it raises an interesting question:

Are our needs really that different, or are we solving the same problems over and over again?

From Proliferation to Saturation

The consolidation discussion predates AI. It predates computing. Humans have always used tools, and making a new tool for every job has always been inefficient.

So why are we joyously baking hundreds of variations of skills like "open a Jira ticket" or "edit a wiki page"? Are our needs really so unique?

My skills analysis identified 3,508 skill locations across just 20 common capability categories. An average of 175 per category. That doesn't mean 175 identical implementations of every capability. But it does raise an interesting question: how much of this variation represents genuinely different needs, and how much is simply reinvention?

Context. That's often the answer.

I've previously published a paper on the power of composed context assembly, exploring how shared capabilities can be adapted to different organizational needs through dynamically assembled context.

But there's a problem that composition alone doesn't solve: repetition.

My skills analysis revealed a landscape of strikingly similar capabilities, implemented over and over again across the enterprise. My analysis of agents revealed a related, but subtly different problem: repeated context across many subagents. Bloated context. Including context assembled by my own engine.

A swarm of subagents, performing similar tasks from different perspectives, would often carry many of the same instructions. Each agent received its own blocks of composed context, sometimes repeating substantial portions of what its peers had already been given.

We had achieved customization. We had achieved reuse. We had even solved much of the problem of distributing organizational knowledge.

But at what cost?

More tokens. More repeated instructions. More opportunities for conflicting guidance. And potentially, more interference with the very reasoning we were trying to improve.

We had solved the problem of getting the right context to the right agents.

Now we had to ask whether we were giving them too much.

The cost was context saturation.

Distillation

Let's take a relatively simple system: code review.

We start with a system prompt, a reviewer persona, Jira ticket information, and a code coverage report. We tell the agent to fetch the PR, extract the diff, read the patch, analyze each line, apply a long list of rules, and definitely, definitely don't do an equally long list of prohibited things.

We've built a highly bespoke skill, packed with situation-specific instructions.

But is this the best way?

So we do what good software engineers do. We abstract.

We extract the common review process into a reusable system prompt. We introduce personas to provide different expert perspectives. We compose organizational rules and domain knowledge through context assembly, injecting the appropriate context for each review.

Now we have a reusable skill, dynamically customized for different teams, repositories, and review scenarios.

Success! Right?

Well, we've taken a huge, specific prompt and turned it into an even bigger, abstract one. The original instructions are still there, and now we've layered dynamically assembled context on top.

Was this better? DRY says so.

We had optimized for reuse, maintainability, and customization. But we hadn't necessarily optimized for the model consuming all this context.

And these are fundamentally different problems.

A system can be beautifully abstracted, perfectly DRY, and still be terribly inefficient at execution.

We had confused software engineering efficiency with context efficiency.

Have We Forgotten the Bitter Lesson?

In 2019, Richard Sutton published The Bitter Lesson. His observation was uncomfortable: throughout the history of AI, researchers repeatedly invested in carefully engineered, human-designed approaches, only to see more general methods eventually surpass them as computation scaled.

And yet, here we are.

We have models capable of reasoning across enormous bodies of knowledge, adapting to unfamiliar problems, and navigating complex workflows.

And what do we do?

We write thousands of lines of instructions telling them how to think.

We prescribe their steps. We anticipate their decisions. We build elaborate orchestration around them. Then we add more instructions to compensate when the results aren't what we expected.

Does any of this sound familiar?

Sutton's lesson wasn't about prompts or agents. But I wonder whether our enthusiasm for engineering every detail of agent behavior is creating a modern version of the same trap.

We may be spending more effort teaching our agents how to solve problems than allowing them to demonstrate what they already know.

That's not an argument for removing constraints or abandoning engineering discipline. It's an argument for questioning which constraints actually improve outcomes, and which simply encode our own assumptions.

Separation

A long-established principle in software engineering is separation of concerns: each component should have a clear responsibility.

Yet the way we write skills today often violates this principle. A single skill might contain a persona's expertise, task instructions, outcome definitions, domain knowledge, and exhaustive rules describing what to do and what not to do.

We've bundled everything together because we want the agent to have everything it might need. But does it really need all of that, all at once?

Research such as Lost in the Middle highlights an important limitation: just because information is present in a model's context doesn't mean the model will effectively use it.

And there's another side to this problem. Simply giving an agent a reference to a file doesn't guarantee that it will read it, either.

These are different failure modes, but they point toward the same architectural opportunity: separating context discovery from context acquisition and application.

Instead of loading every piece of potentially relevant information up front, we can make it discoverable and allow the agent to retrieve what it needs, when it needs it. Essential instructions can remain explicit, while supporting knowledge and evidence can be loaded on demand.

This is why we encourage keeping CLAUDE.md and AGENTS.md files lean, focused on guidance that applies to most operations within a repository rather than every possible scenario.

The same principle applies to skills.

Let's return to our pull request review example. What if, instead of embedding the review process, expertise, evidence, and classification rules into one enormous prompt, we separated them into distinct artifacts?

Skill body:
You are reviewing a pull request.

The patch is here: <path to patch>
The PR description and conversation: <path to PR JSON>
Your expertise: <path to expert lens>
The Jira story and discussion: <path to Jira JSON>
Code coverage: <path to lcov report>
Finding severity guidelines: <path to severity guide>

Apply your expert perspective to the PR.
Use the available evidence and guidelines to identify
and classify meaningful findings.

Notice what we've removed.

We're no longer telling the model how to read a patch, how to walk through every line, or prescribing a long sequence of reasoning steps. We're giving it a task, a perspective, access to evidence, and the criteria for evaluating its findings.

The skill describes what the agent needs to accomplish, not every step it must take to accomplish it.

Of course, there's a tradeoff.

We can't guarantee that the model will read every referenced file. But loading everything into its context doesn't guarantee that it will reason over everything, either.

The challenge isn't simply to provide less context. It's to ensure that essential context is acquired and applied, while avoiding the cost of loading everything indiscriminately.

And perhaps most importantly, to recognize that making knowledge available to an agent is not the same as making that knowledge useful.

Personas, Prompts, Pink Elephants, Oh My!

You may have noticed that in my example, I didn't talk much about guardrails. I didn't spend exhaustive effort telling the model what it may not do.

This brings me to the "pink elephant problem."

Tell someone not to think about a pink elephant. What's the first thing that comes to mind?

A pink elephant, of course.

Models aren't people, and they don't necessarily respond to negative instructions the way humans do. But there's an interesting parallel: every instruction we add introduces more concepts, conditions, and potential distractions into the model's context. Even the things we're telling it not to do.

There's an interesting lesson here for how we write agent instructions.

Rather than exhaustively describing everything an agent must not do, perhaps we should spend more effort describing the behavior we actually want.

"Don't do X" tells the model what to avoid. "When encountering X, do Y instead" gives it a constructive path forward.

This doesn't mean negative instructions are inherently bad, or that security boundaries should be left to clever prompt engineering. Permissions, sandboxing, and authorization belong in enforceable systems wherever possible.

But when we're describing how an agent should perform its work, I suspect we could eliminate a surprising amount of unnecessary instruction simply by focusing on desired outcomes rather than anticipated mistakes.

And that brings us back to the question: how much of our carefully engineered context is actually helping?

So much has changed. Yet so much stays the same

Models have improved by leaps and bounds over the years, but these insightful papers expose concepts that have outlasted the AI models of their time. We've spent the last two years learning how to give agents more capabilities, more instructions, and more context.

Perhaps the next challenge isn't figuring out what else we can give them, but understanding what they actually need.

That means separating capabilities from expertise, evidence from instructions, and constraints from execution. It means making context discoverable without making all of it mandatory. And it means being willing to question whether our carefully engineered prompts are helping the model, or getting in its way.

The next frontier may not be how much context we can assemble.

It may be how much we can leave out.

This paper describes a general system model for AI execution at scale. While informed by real-world experience, it is not specific to any single organization or implementation.

The Problem: Inconsistency at Scale

Organizations are rapidly moving from small-scale AI experimentation to broad, enterprise-wide adoption. What works for a handful of individuals  -  prompting, ad-hoc workflows, locally defined tools  -  begins to break down as usage scales across hundreds or thousands of people. At that scale, the problem is no longer access to capability. It is consistency of execution.

To address this, we introduce a model we refer to as Context-Assembled Execution (CAE).

In this model, behavior is not embedded in tools or reconstructed through prompting. Instead, it is assembled dynamically at the moment of execution from structured layers of context.

This paper describes CAE as a system pattern, and introduces DCAP (Dynamic Context Assembly Platform) as a reference architecture for implementing it.

Together, they define a shift in how AI systems operate at scale:

• CAE defines the execution model

• DCAP provides the system that makes it real

In large organizations, we've seen teams independently build overlapping solutions to the same problems. Similar tasks produce different outcomes depending on who invokes them. Organizational standards are applied unevenly, if at all. Context is copied, repeated, and lost. Costs grow unpredictably as systems rely on increasingly large and redundant inputs. What begins as acceleration at the individual level does not stabilize as it scales. It compounds.

Each new team introduces its own variations. Each variation becomes another branch of behavior to maintain. Context grows, but not coherently  -  copied across prompts, duplicated across tools, and redefined in slightly different ways. Over time, the system does not converge toward consistency. It diverges.

The Problem: Divergence at Scale - when teams build in isolation, similar work produces different outcomes, context is duplicated, standards drift and costs grow unpredictably

At scale, this creates a failure mode that is already beginning to surface in large organizations. Organizations lose the ability to reason about how work is being performed. Outputs become unpredictable. Standards become advisory rather than enforced. Trust in automated systems erodes - not because they are incapable, but because they are inconsistent.

In many organizations, this transition is subtle. It does not appear as a single failure, but as a growing loss of alignment that becomes harder to correct over time. This is the point at which adoption stalls. This is the point when costs go exponential. This is when the system fails - not due to lack of capability, but due to lack of control.

Why Current Approaches Don't Readily Scale

This is not a limitation of the underlying models. It is a limitation of the systems built around them.

Most current approaches treat capabilities  - skills, tools, agents  - as the primary unit of design. Behavior is embedded directly into these capabilities, or reconstructed through repeated prompting at the point of use. Both approaches fail to scale. Embedding behavior leads to duplication and drift as teams fork and customize implementations. Prompting relies on human consistency that does not exist at enterprise scale.

What is missing is a consistent way to govern how work is executed without constraining who performs it.

This becomes immediately visible in even the simplest workflows. A task like creating a Jira ticket appears uniform, but in practice varies widely across teams  - each with different fields, standards, and expectations. Without a consistent way to apply that context at execution time, behavior fragments, duplication increases, and outcomes diverge. The diagram below illustrates how this variation emerges - and why it compounds as systems scale.

Why Current Approaches Don't Scale

A Different Approach: Context as the Source of Behavior

Most systems attempt to solve this problem by enforcing behavior directly.

They embed rules into tools, define rigid workflows, or rely on repeated prompting to shape outcomes at the moment of use. At small scale, this works. At enterprise scale, it breaks. Rules become brittle, tools diverge, and prompting becomes inconsistent. The system fragments because behavior has no stable place to live.

The approach described here is based on a different premise: that governance should not be enforced mechanically, but interpreted dynamically.

Instead of encoding behavior into capabilities, this model introduces a context assembly layer that defines how work should be performed at the moment it is executed. Organizational standards, team conventions, and individual expertise are not embedded in the tool  - they are assembled, layered, and presented to the model as structured context.

There is no rigid rules engine enforcing behavior through fixed pass/fail logic. The model itself becomes the governing mechanism, reasoning over structured context the same way an experienced practitioner would - evaluating constraints, resolving conflicts, and applying judgment.

This shifts the role of the system entirely. Instead of enforcing behavior, it shapes it. Capabilities remain simple. Context becomes authoritative. And governance moves from something the system executes to something the model understands.

Context as a source for a scalable Jira capability

Context-Assembled Execution (CAE)

Context-Assembled Execution (CAE) is a model for AI systems in which behavior is not embedded in capabilities but dynamically constructed at execution time from layered context.

Instead of encoding rules into tools or relying on repeated prompting, CAE externalizes behavior into structured context layers - such as company policy, organizational standards, and individual expertise - which are assembled and interpreted by the model at the moment work is performed.

This model mirrors the CSS cascade: context is composed top-down from layers of authority, while resolution occurs bottom-up, where more specific context overrides more general guidance.

In CAE:

• Capabilities remain simple and reusable

• Context defines behavior

• Governance is applied dynamically, not enforced statically

This enables consistent execution at scale without sacrificing flexibility, allowing systems to converge over time rather than fragment.

Dynamic Context Assembly Platform (DCAP)

DCAP (Dynamic Context Assembly Platform) is a reference architecture for implementing Context-Assembled Execution.

It provides a runtime system that:

• Collects context from layered sources of authority

• Assembles that context dynamically at execution time Injects it into model-driven capabilities

• Produces governed outcomes based on interpreted context

DCAP functions as a control plane for AI execution, enabling consistent, policy-aware behavior across teams, systems, and environments.

How Authority Cascades and Evaluates in DCAP - Context is composed from layers of authority (top-down) and resolved by specificity (bottom-up), similar to CSS. More specific context overrides more general guidance.

Reference Architecture: Context-Assembled Execution

At a high level, the system consists of four components:

Capabilities:
Discrete functions that perform work, such as generate code, review a change, execute a workflow - these are typically skills or plugins in many AI systems today

Context Layers:
Structured layers of guidance defined at different levels of authority: company, org, team, repo, individual Each of these layers contributes uniquely to the constraints, preferences, and domain specific knowledge necessary to execute a task

Context Assembler:
A runtime component responsible for gathering and composing context from all of these layers at the moment of execution.

Execution Engine:
This is the model invocation itself, which receives:

• The requested capability  -  for example, a pull request capability

• The assembled context (for example, an engineer in the Rocket division at Acme Corp, operating within a repository with defined architecture patterns, ownership rules, and team standards)

• The user's input

The model interprets the combined context and produces an outcome

Example: Pull Request Review

Let's take an example of a common operation developers perform daily  -  reviewing a pull request.

In the traditional system, review logic is embedded in personal knowledge, or perhaps automated as a prompt, copied and pasted and tweaked. Maybe you have created a skill, and others have installed that skill and tweaked it to reflect their style or focus.

What happens when we do this?

• Review logic becomes embedded in scripts or prompts

• Teams and individuals fork and modify behavior

• Standards blur and drift over time

Let's look at a new model:

A new model for AI systems

At runtime, these layers are assembled into a structured context with a preamble describing to the model how to interpret them. The capability has no embedded knowledge of the domain-specific context being injected.

What the capability is aware of is HOW, WHERE and WHY it will consume assembled context. This means that the skill is aware of its role in an enterprise scale system, and it is intentionally abstract, deferring all non-essential decisions to the policy layers.

In our example, a pull request capability knows how to open a pull request, read the diff and then some fundamental instructions, such as "suggest inline changes where appropriate. Explain your rationale for feedback. Give the user a recommendation." These do not change across an enterprise. These represent the most abstract definition of a pull request review. The key is that the capability knows that it should load the effective policy for this user and apply it to the underlying fundamental tasks  -  a policy aware capability understands its place in an enterprise.

Key Properties of the Model

This architecture introduces several important properties:

Separation of concerns
Capabilities perform work. Context defines behavior.

Dynamic governance
Rules are evaluated and applied at execution time, not enforced statically.

Composability
New context layers can be added without modifying capabilities.

Convergence over time
Improvements to capabilities benefit all users.
Improvements to context refine behavior locally without fragmentation.

DCAP is a control plane for AI execution. It assembles the right context at the right moment, lets the model interpret it, and governs the outcome - action by action.

DCAP control plane architecture

Contrast With Existing Systems

Most current systems embed behavior in one of two places:

• Inside the capability itself

• Inside repeated prompts at invocation time

Both approaches lead to duplication and drift. In this model, behavior is externalized and composed dynamically, allowing the system to scale without fragmentation.

How the System Scales: Layered Context

This separation has a direct impact on how capabilities evolve over time.

In most mature systems, variation does not live inside the capability itself. It is defined externally - through layered configuration, policy, and override. Infrastructure behaves differently across environments without being rewritten. Identity systems enforce global standards while allowing local exceptions. Interfaces adapt through cascading rules rather than duplication.

AI systems are currently missing this layer entirely. In many environments, tools and scripts proliferate because variation has nowhere else to live. A capability that performs well in one team is copied and modified for another. Small differences in workflow, naming, validation, or policy become embedded directly into the implementation. Over time, the organization accumulates multiple versions of the same capability, each partially maintained and inconsistently applied.

This is not a new problem. It is a solved one - just not yet applied to AI. Many languages and systems have faced this evolution.

Early systems often embedded structure and behavior directly into rigid, verbose formats. XML became a standard for representing data and configuration, but at scale it proved difficult to work with  -  too heavy, too repetitive, and hard to evolve.

JSON emerged as a simpler alternative, reducing friction and making data easier to compose and consume. Later, formats like YAML further optimized for readability and layered configuration, allowing systems to express variation more cleanly without duplicating structure.

The pattern is consistent: as systems scale, structure moves out of rigid implementations and into more flexible, composable layers.

AI systems are now encountering the same transition.  

What XML was to early systems, embedded behavior and prompt duplication are to AI today.  

What JSON and YAML enabled  -  clear, layered, composable structure  -  is what context assembly introduces for AI execution.

Evolution of Data and AI Systems :  Two evolutions. The same pattern.

When context is externalized, variation moves out of the capability and into the layers that define how it should behave in different situations. A single implementation can serve many contexts, shaped at execution time rather than rewritten at design time. Improvements to the capability benefit every team that uses it, while improvements to context refine behavior locally without creating divergence.

The system begins to converge instead of fragment. Capabilities stabilize. Context evolves. And investment compounds across the organization rather than being diluted by duplication.

Layered Authority and Context Composition

In systems that operate at scale, this kind of control is not achieved through a single source of truth, but through layers of authority.

This pattern is not unique to AI. It is how enterprise systems have long managed complexity  -  through structured hierarchies of policy, configuration, and override.

Global standards define what must always be true. Organizational and team-level guidance refine how those standards are applied. Local environments introduce specificity. Individuals retain the ability to adapt behavior based on context and experience. Each layer contributes, and each layer has a clear scope of influence.

The same structure applies here.

Without layering, governance collapses toward one of two extremes: it becomes too rigid to adapt, or too loose to enforce.

Context is assembled from a hierarchy of layers, each representing a different level of authority - from company-wide guidance to individual preference.

It is not loaded in advance or applied globally. It is assembled in response to action.

When work is about to be performed  -  whether generating code, reviewing a change, or executing a workflow  -  the system gathers the relevant context from each layer and composes it at that moment. The model receives not a static policy, but context that is specific to the action being taken.

When layers disagree, resolution follows the simple pattern already proven by CSS: more specific context overrides more general guidance, with the ability for any layer to define non-overridable constraints where required. This ensures that governance is applied precisely where it matters  -  at the point of execution  -  rather than carried broadly across unrelated work.

This is not a static configuration. It is a dynamic composition of guidance that reflects both global standards and local nuance  -  applied at the moment work is performed.

Redefining Contribution in AI Systems

Same Skill, Different Context, Different Outcome

This model changes how individual contribution is defined.

In traditional workflows, contribution is measured by the artifacts a person produces. As execution becomes increasingly automated, that definition breaks down. The value is no longer limited to the output itself, but to the context that shapes how that output is generated.

In this system, individuals do not just produce results. They define how results are produced.

By encoding their judgment, preferences, and domain knowledge into their own context layer, their contribution persists across every task they perform. It compounds over time, shaping the behavior of otherwise generic capabilities and producing outputs that reflect their expertise rather than replacing it.

At the same time, this model does not require that expertise to be centralized. Individuals retain control over what remains local and what is contributed upstream. This preserves autonomy while still allowing collective improvement.

The result is a system where expertise is not embedded in isolated artifacts, but continuously applied - visible in every outcome, without needing to be manually reintroduced.

Conclusion: Context Defines Behavior

As AI systems take on a larger role in execution, the question is no longer what they are capable of, but how their behavior is shaped.

Systems that treat context as incidental will produce outputs that are technically correct but operationally inconsistent. Systems that embed context directly into tools will fragment a s variation accumulates. Neither approach can sustain scale.

What is required is a model in which context is not an afterthought, but the primary mechanism of control.

This is not a new idea. It is how complex systems have always operated - through layered authority, dynamic composition, and context applied at the moment of action. AI systems have simply lacked this layer.

The result is a shift in how we think about execution itself.

Capabilities no longer define behavior. Context does.

Governance is no longer enforced by the system. It is understood by the model.

And scale is no longer achieved by standardizing tools, but by shaping the context in which those tools operate.

Once this layer exists, the problem changes.

The question is no longer how to build better capabilities.

It is how to define the context that makes those capabilities behave correctly  - every time, across every environment, for every user.

That is the system.

That is how AI behaves consistently at scale.

But after building production AI systems inside enterprise engineering workflows, I keep coming back to a simpler observation:

Most “agents” aren’t autonomous systems.

They’re deterministic workflows with probabilistic branching.

Or, as Inigo Montoya might say:

“You keep using that word. I do not think it means what you think it means.”

What does "Agent" mean?

agent

/ā′jənt/

noun

1. One that acts or has the power or authority to act.

2. One empowered to act for or represent another.

3. A means by which something is done or caused; an instrument.

Clearly it is obvious why we have chosen the word "agent". We are constructing prompts and systems to perform work for us.

In AI, and in software in general, an "agent" is defined as:

a software system that autonomously perceives its environment, makes decisions, and takes actions to achieve specific goals with minimal human intervention

Stop. Read that. Now read it again. Notice what is NOT there. It never says AI. It never says LLM. It never says model. It says "a software system". Can this software system use AI? Absolutely. Must it?

No.

An Agent does work for you. That's it.

Does it have to be a fancy ai model that spends 1k tokens per second to process some data that you can jq on the command line? Sure. It can be. But should it?

Does it have to dynamically write python based on a prompt that says "examine the state of my system, and call my jenkins end point and if there are failing jobs, and they have failed more than 5 times parse their logs?". Sure. But should it?

Once more for the folks in the back: no.

Don't ask the model to do what you can do better

This isn't about tokens. This is about common sense. You want to agentify a workflow? Fabulous. You know exactly what you want it to do.

Write that code.

When you cannot efficiently perform a task statically, that's when you call for backup. Ask the model. Do some inference. Build a targeted prompt. Give it exactly the context it needs.

It doesn’t benefit from inheriting every tool call, every log, and every piece of system state. It certainly doesn’t benefit from ten minutes of token burn in KV cache. In fact that often has the opposite effect. The model is far more likely to try to optimize for some result it infers from the progression of that huge leadup. Or, in other words: hallucinate. Most often hallucination comes from muddy context.

Your “Always-On Agent” Is Probably a Webhook

Lately the hype has shifted. Not just agents, now it's "always on agents". Agents that monitor your repos. Watch your pipelines. Track your incidents. Review your pull requests. Work while you sleep.

Sounds impressive, doesn't it?

But here’s the uncomfortable truth: This isn’t new. We’ve been building event-driven systems for decades. The only difference is that now we sometimes insert inference into the chain.

A pull request opens. A CI build fails. A queue receives a message. A cron job wakes up.

In other words: software happened.

Not an agent sitting in a dark room “thinking.” Not a model continuously reflecting on your infrastructure. Just an event-driven system doing what software has done well for decades.

And yes, we can absolutely push this further.

We can hand the model the keys and make it the orchestrator:

You are an autonomous build monitoring agent.
Check Jenkins for failed jobs.
If a job has failed more than 5 times:
  - Fetch the last 100 log lines
  - Compare with previous failures
  - If the failures are similar, notify the owning team
  - If the failures differ, open an investigation issue

If no failures exist:
  - Sleep and check again in 5 minutes

Can an LLM do this?

Absolutely.

Modern models are surprisingly good at tool calling, branching logic, and dynamic execution planning.

But here’s the uncomfortable question:

Why are you asking a probabilistic system to perform deterministic orchestration?

Polling.
Branching.
Retries.
Threshold checks.
Ownership routing.
Backoff.
Circuit breaking.

These are not "unsolved AI problems".

These are software engineering problems. And software already solves them extremely well.

Every time you move deterministic control flow into a model, you introduce:

• more latency

• more cost

• more nondeterminism

• more debugging complexity

• more opportunities for hallucinated control flow

So where should the model live?

Not here:

LLM → Observe → Branch → Retry → Decide → Route

But here:

Code → Observe → Filter → Branch → LLM → Directional Inference → Code

Let software own the workflow. Let the model own the ambiguity.

That’s where AI starts becoming leverage instead of theater.

Stop Paying Inference Tax For Deterministic Logic

You know the drill. You write a prompt. Your agent starts to work, and you watch your tokens drip drip drip away. And somewhere in that process you start to notice: "gee did it really just cost 1k tokens to do a git pull?". Yes. Yes it did.

Every time you move deterministic control flow into a model, you pay an inference tax:

• latency
• cost
• nondeterminism
• observability gaps
• harder incident debugging

Do you really want to spend tokens and introduce complexity for a task that you can do reliably, repeatably, and more quickly - for free?

Or do you want to take that process, and use ai to build a script that delegates to llm calls when inference is the only solution? Spend those tokens once, build a bash script. a node script, a python script. A combination of the 3, leverage node for json, leverage python for strings, leverage bash for cli delegation.

Write software.

Then you can define a skill. the skill says a few short lines:

I am an orchestration agent for the Acme Corp Code Builder:
I am fired by the git commit action:
run the ./build.sh script
```sh
./build.sh > build.log
```

if we have failures, run ./analyze-build-failures.sh
```sh
./analyze-build-failures.sh build.log > actions.json
```
review actions.json. take the actions recommended.
...
etc

In each of these scripts, you use static code to do any static steps. Why? because it's free. Can an AI do it? Sure, for a price. For a few hundred or thousand tokens.

But when you have genuinely probabilistic work:

  const response = await client.responses.create({
    model: "gpt-5",
    input: `
You are a senior SRE.

Analyze these repeated CI failures and tell me:

1. Are these likely infrastructure issues, test flakiness, or code regressions?
2. What should an engineer check first?

Jobs:
${JSON.stringify(concerningJobs, null, 2)}
`
  });

Now your AI is doing exactly what AI is built for. Making inferences. Making judgment calls. Augmenting your deterministic code with the power of AI.

You need software for that

So, no, you didn't need an "agent" for that. You needed software for that. Software that leverages AI in exactly the right place to make the jump from "cool script" to "system critical sentinel"

Is it still "an agent"? Sure. But it's an "ai agent". It's an ai-augmented software agent. A proven software architecture — now augmented with targeted inference where judgment actually matters.

The next time someone says, “We need an agent for this.” Ask a simpler question first:

Do we need an agent? Or do we just need better software?

Often, once you distill all the hype, the answer is "we need SOFTWARE for this!"