There are two familiar ways to run an agent over real work. In model-driven execution, the model organizes operations and decides what happens next. In a predefined workflow, an execution engine follows explicit dependencies and branches, calling an LLM only where a step genuinely needs one.

This article explores a middle path: agents author and revise workflows, while routine execution proceeds without model supervision. The hypothesis behind it is that a dynamic decision — the kind a model makes once, under pressure, with full context — can become a reusable, persistent execution capability.

That is a design hypothesis, not a result. I built a small runnable spike to check whether the core mechanics hold up, and they do. Whether the surrounding infrastructure is worth its cost remains genuinely open, and most of this article is about why.

What should stay dynamic?

A model needs global knowledge to plan and adapt. Repeated, verifiable work usually does not need it. If those two claims are both true, the interesting question is not “agent or workflow” but which decisions have to be made fresh every time.

The middle path answers: almost none of them, on the normal path. The model’s job moves from permanent driver to a capability invoked on deviation — and, more importantly, to an author of the machinery that handles the next deviation mechanically.

The cost of that answer is infrastructure: contracts, versioned operators, persistent execution state, evidence assembly, validation, rollback. That is a lot of machinery to justify, which is why the motivating case matters.

The motivating case: a long-running vendor integration pipeline

Consider a service that uploads and downloads vendor data, passing through an integration layer and several internal services with data dependencies between them. It processes tens of millions of records and thousands of API calls daily.

Most of that execution is routine. But its assumptions change occasionally:

  • A vendor SDK or API is upgraded.
  • The network is unstable for an hour.
  • Internal data arrives late.
  • An upstream dependency or data contract changes.

The shape of the work is what makes it interesting: execution is frequent, adaptation is occasional. A validated change serves many subsequent runs, so its authoring cost is spread over substantial work. That ratio is the only reason this architecture has a chance of paying for itself. A one-off job does not have it.

I should be clear up front that my spike does not model this pipeline. It models a much smaller repository-migration mock. I will come back to that gap in the spike section, because it determines what the evidence can and cannot support.

It helps to separate two things that often get discussed together.

Software architecture that supports agent maintenance. Expose evidence, contracts, dependencies, and recovery interfaces so that an agent can assist with triage and upgrades on a system you already have. This is mostly an observability and interface problem.

Harness infrastructure that agents can program. Provide abstractions through which an agent creates persistent, reproducible pipelines and revises its own capabilities. This is a runtime problem.

The second is the subject here. The vendor pipeline is the test case: does a programmable harness actually support useful maintenance behavior on work of that shape?

Separating execution, triage, and orchestration

The design splits three responsibilities that model-driven harnesses usually merge.

Operators and the execution engine

Operators are usually ordinary code: transform data, call an API, check a dependency, validate a result. Some are model-backed, but most should not be.

The engine handles scheduling, state, predefined retries, waiting, and event collection. On the normal path, no model participates.

The triage agent

Triage is invoked when mechanical handling cannot resolve or classify a problem. It examines a bounded evidence package, identifies the likely cause and affected scope, and then either selects an existing recovery procedure or escalates.

One rule matters more than the rest: aggregate and deduplicate failures before invoking triage. A single vendor outage should produce one evidence package, not one model call per failed request. Without that, the “fewer model calls” argument inverts immediately — a bad hour becomes thousands of inference calls that all reach the same conclusion.

The orchestrator

The orchestrator is invoked when recovery requires broader reasoning or actual change. It uses global goals, contracts, dependency knowledge, and incident evidence to plan recovery, author operators, or revise the workflow definition itself.

Note what this implies about context. Global knowledge persists outside a continuously active model conversation — in contracts, dependency records, and incident history. Relevant context is assembled when needed, not accumulated forever in a parent session that grows until it is unusable.

The agent-programmable framework

Three abstractions carry the design.

Operator abstraction

An operator defines:

  • Input and output contracts — what it consumes and produces.
  • Applicability conditions — where it may run, and where it must not.
  • Implementation and permissions — the code, and the authority it is allowed to exercise.
  • Validation criteria — how its result is checked, independently of whether it exited cleanly.
  • Failure and escalation behavior — what it does when it cannot proceed, and what evidence it hands back.
  • Version identity — so a run records what actually executed, not what is currently installed.

Model-based operators additionally define how their local context is constructed. That construction is part of the contract, not a prompt detail.

The spike implements a reduced version of this shape:

1
2
3
4
5
6
7
8
9
@dataclass
class Operator:
    name: str; version: str
    inputs: tuple[str, ...]; outputs: tuple[str, ...]
    applicable: Callable[[dict], bool]
    context: Callable[[dict], dict]
    implementation: Callable[[dict, dict], dict | Intervention]
    validate: Callable[[dict, dict], dict]
    permissions: tuple[str, ...] = ("read_repo", "write_workspace")

Workflow abstraction

The important separation here is between a workflow definition and an execution instance.

A definition describes dependencies, data mappings, conditions, and the operator versions it pins. An instance preserves progress, artifacts, validation evidence, and recovery history for one run.

Keeping them apart is what makes revision safe. You can author a new definition without disturbing in-flight instances, and you can inspect an instance to see exactly which operator versions produced which artifacts. The framework then exposes interfaces for agents to construct, inspect, validate, and revise workflows — validation before activation, not after.

Intervention protocol

1
2
Detect deviation → Preserve state → Assemble evidence → Triage
                 → Escalate if necessary → Validate recovery → Resume

The action set should begin bounded: retry, wait, supply corrected inputs, run a repair subworkflow, replace an operator version, or terminate. An open-ended action menu is tempting and almost certainly wrong before the contracts and the side-effect policy are mature. A retry around a compiler is one thing; a retry around an external write is another.

One adaptive repair, start to finish

Take a vendor SDK upgrade that changes request-signing behavior.

  1. API failures start exceeding the existing recovery policy. Retries do not help, because the requests are wrong, not unlucky.
  2. Failures are aggregated into one incident. Triage correlates them with the upgrade window and rules out the competing explanation — missing upstream data.
  3. Triage has no existing procedure for this, so it escalates. The orchestrator inspects the changed contract and revises the integration operator.
  4. The candidate is validated with contract tests and representative samples, not by being run against production traffic and watched.
  5. The new operator version is introduced with a rollback path. Activation is a deliberate step, and reversible.
  6. Affected work resumes from preserved instance state, without duplicating side effects that already completed.

The distinction worth naming here is between operational recovery and adaptation. Retrying restores a run. Changing an operator changes how future runs behave. They need different evidence, different authority, and different audit trails — and conflating them is how an agent quietly rewrites a pipeline because one request failed.

How experience becomes mechanical

If adaptation stays a one-off, nothing has been gained over a capable engineer with a terminal. The value, if it exists, comes from accumulation.

There are two forms:

  • Successful repairs become reusable operators or recovery workflows.
  • Repeated diagnoses become detection and routing rules.

Together these produce a promotion ladder. An exception may initially require orchestration; later it requires only triage, because a routing rule recognizes it and a known procedure handles it; eventually it is handled mechanically, with no model call at all.

The constraint on that ladder is evidence. Promotion requires knowing where a capability applies and that it is correct there. A successful one-off repair is a candidate for reuse, not proof that it generalizes. Promoting on a single success is how a harness learns a wrong lesson and then applies it at volume, which is strictly worse than not having learned anything.

Where the economics might work — and where they might not

The comparison has to be against strong baselines, not against a strawman:

  • An existing workflow engine maintained by engineers.
  • An agent using mature scripts and tools, with subagents for isolated context.
  • The proposed framework, with conditional triage and orchestration.

The second baseline is the hard one. If your scripts are already good, most of the “model overhead” the framework removes was never being paid.

Potential benefits: reduced maintenance effort, faster recovery, fewer routine model calls, and reuse of validated changes across many runs.

Real costs: writing and maintaining contracts, assembling evidence, verifying candidate repairs, versioning and activating operators, and — the one that is easy to underweight — failures introduced by incorrect repairs. An agent-authored change that passes its tests and is wrong in production is a new failure mode that neither baseline has.

High volume alone does not establish value. Tens of millions of records per day justify nothing by themselves if the pipeline rarely changes. The benefit depends on three conjunctive conditions: maintenance needs that recur, adaptations that are reusable rather than bespoke, and validation that is cheap enough to run before activation. Miss any one of them and the framework is architecture for its own sake.

The spike I actually ran

Here is the honest part. The spike is a repository-migration mock, not the vendor pipeline. It is stdlib-only, deterministic, and touches no real project. It uses a rule table in place of a model, so it makes no LLM calls and counts no tokens.

What it does exercise — and this is the part I wanted concrete evidence for — is the core mechanics:

  • Deterministic operators with contracts, validators, applicability, declared permissions, and version identity.
  • A workflow definition validated before execution (operator references resolve, dependencies are already defined).
  • Persistent execution state: node status, artifacts, validation evidence, and the operator version actually used.
  • Pause on an exception, assemble a targeted context, hand off, apply a bounded recovery action, and resume the same node.
  • Extraction of a repair into a registered operator, and its reuse on held-out work.

Seven mock repositories: two ordinary, one with malformed structured output, one with a transient infrastructure failure, one with a legacy compatibility wrapper, and two holdouts (zeta, eta) kept back while the repairs were authored. Rerun it with:

1
python3 spike/harness.py

The captured run:

Approach Accepted Human interventions Wakeups Handoff context (chars) Repeated nodes Global decision points
Fixed workflow 2/7 5 0 0 0 0
Model-driven (mocked) 7/7 0 0 0 0 40
Wake on exception 7/7 0 5 7,330 5 0

The five wakeups correspond to three exception categories across five repositories. repair_structured_output and migrate_legacy_wrapper were extracted and then reused by the holdouts. Wall time was 0.226 ms, which is only a sanity check that the mock ran.

Several of those numbers are modeled rather than observed, and it matters which. The fixed workflow’s five “human interventions” are stipulated: anything the predefined branches do not cover is counted as needing a person. The model-driven row’s 40 global decision points is likewise an accounting convention — five per repository plus one for each exception — not a measurement of a real agent.

Any inference-cost implication is an estimate by guess, not a measurement. The spike made no model call, counted no tokens, and reports no currency figure. “Global decision points” is a relative accounting device that makes the premise plausible; it does not price it.

And the spike does not exercise most of what this article proposes:

  • No incident aggregation or deduplication. Each exception wakes the orchestrator individually — exactly the behavior the design says to avoid.
  • No distinct triage role. One deterministic decision function plays both triage and orchestrator, so the article’s central separation is untested.
  • No controlled activation or rollback. Extracted operators are registered immediately at version 1.0 and used; there is no gate and nothing to roll back to.
  • No second round against unseen variations. The holdouts are fresh repositories, but they belong to categories the repairs were authored for. That tests reuse, not generalization.
  • No real side effects, no real contracts, no real vendor. Nothing here validates the vendor pipeline’s economics.

So the spike supports one narrow claim: the mechanics are implementable and behave as designed on a toy. It supports nothing about whether they are worth building.

What would justify building more?

A proper evaluation would be two rounds, not a demonstration. First let the system encounter exceptions and author repairs. Then run fresh work — including variations the repairs were not authored for — and measure recovery correctness, human intervention, time to recovery, repeated side effects, real model cost in a model-backed setup, and the effort to author, validate, version, and maintain the operators.

The approach would earn its complexity if: exceptions recur in recognizable categories; validated repairs measurably reduce intervention on later work; validation is cheap enough to gate activation; and incorrect repairs are caught before they reach production. It would fail if reuse degrades on unseen variations, if evidence assembly and contract maintenance cost more than the model calls they replace, or if a capable agent with mature scripts matches the result without any of the runtime.

I would build the incident aggregation and the triage/orchestrator split first, in that order. They are the two pieces the current spike skips, and they are where the cost argument is decided.

Which returns to the question this was all meant to test:

Can an agent-programmable harness turn occasional reasoning into durable execution capabilities, at a lower total cost than maintaining the pipeline directly?

I do not know yet. The mechanism works. The economics are unproven, and on current evidence I would not assume they hold.