Every successful agent run should make the next one cheaper

An agent system should need less intelligence to solve the same class of problem the second time. Many systems instead pay the full price again: they reload context, rediscover tool behavior, repeat a failure, and ask a capable model to reconstruct the procedure from scattered traces. Better memory can make that repetition less wasteful, but it does not establish that the organization learned.

The next compounding advantage in AI will come from systems that convert experience into validated, executable institutional knowledge. They should also prove that later repetitions use less inference, less time, and less human intervention without hiding a higher error rate. This is a BaristaLabs architectural argument and a proposed measurement approach, rather than evidence that a particular product has already achieved it.

Every run can create an outcome and a reusable capability

Tokens, context windows, tool calls, and human review are operating expenses. They buy the current result and then disappear. A verified procedure, a tested adapter, a dependency index, or a release check can act more like capital because it lowers the cost or risk of future work.

We can call that durable value inference capital: a validated artifact that reduces the reasoning, retrieval, tool use, or review needed for a later task. Its capability yield is the future operating expense it avoids relative to what the organization spent creating and maintaining it. Yield can appear as fewer tokens, fewer calls, shorter elapsed time, less review, or fewer recoveries, but only when the saved artifact remains applicable and correct.

Creating reusable capability also imposes a factory tax. Someone has to extract the lesson, generalize it, state its boundary, write tests, check permissions, and keep it current. Capability depreciation is the loss of expected value when repositories, tools, policies, data shapes, or business rules change. An instruction that once saved time can become an expensive source of false confidence.

The investment rule is therefore selective:

P(recurrence during the evaluation horizon) × total savings if it recurs × confidence > creation + verification + maintenance + expected failure cost

Treat every term as a cost in the same unit and over the same horizon.

In plain language, preserve a lesson when the task is likely to recur, the expected savings matter, and the evidence supports reuse strongly enough to cover the full lifecycle cost. A rare task with a brittle workaround should remain an episode in the history. A recurring task with stable preconditions and a testable result may deserve promotion into a maintained capability. Skillizing everything raises the factory tax and creates more choices for the runtime to get wrong.

This extends the standard we set for what a first AI pilot should leave behind. A task can produce an immediate result and a reusable capability, just as a pilot can produce a decision and durable evidence. The important distinction is that a saved artifact becomes capital only after it can survive another run.

The harness should compile experience instead of merely storing it

A conventional agent harness prepares context, exposes tools, runs a model, and records a trace. A capability compiler adds a second job: it turns selected experience into a reusable unit whose behavior and limits can be checked before runtime. The word “compiler” matters because the output is executable and validated, rather than a summary that happens to sound authoritative.

The full path is task execution → raw trajectory → candidate lesson → generalized procedure → typed contract → tests and counterexamples → validated capability → runtime selection and composition. A SKILL.md file may be one human-readable projection of that capability. The compiled output also includes its contract, dependencies, evidence, test results, environment assumptions, permissions, and invalidation rules.

EXPERIENCE  task execution → raw trajectory → event graph → candidate lesson
COMPILE     candidate lesson → capability compiler → generalized procedure → typed contract
VERIFY      typed contract + tests + counterexamples + counterfactual replay → verifier
ADMIT       verified candidate → policy admission → promote / specialize / merge / retire
RUNTIME     admission decision → validated capability graph
            task → router → select + compose from graph → execute
OUTPUTS     capability graph → generated root projection
            execute → telemetry → maintenance / retirement → event graph

The event graph records what happened. The compiler proposes a reusable procedure. The verifier attacks that proposal with known failures, counterexamples, and counterfactual replay: it reruns earlier cases as if the candidate capability had been available, then checks whether it would have helped, changed a correct decision, or widened a failure. A policy admission layer decides whether the candidate may enter the runtime graph, at what scope, and with which permissions.

That separation is essential. The same worker that found a useful shortcut should not be the only authority deciding that every future worker must follow it. Our analysis of AI model bake-offs makes a related point: evaluation machinery can inherit assumptions from the system it already knows. Admission needs adversarial replay, not agreement between a trajectory and its own summary.

A capability needs a typed interface and an explicit failure surface

The runtime needs enough structure to decide whether a capability applies before loading or executing it. A compact Capability ABI supplies that structure. The name borrows from an application binary interface: this contract defines how a capability connects to the surrounding system without requiring the router to reinterpret its prose on every run.

capability:
  goal: "The outcome this procedure can produce"
  preconditions: []
  inputs: { schema: {}, required: [] }
  outputs: { schema: {}, acceptance: [] }
  side_effects: []
  permissions: []
  invariants: []
  known_failure_modes: []
  counterexamples: []
  environment_fingerprint: {}
  expected_cost: { tokens: null, tools: null, time: null }
  evidence: { cases: [], tests: [], confidence: null }
  dependencies: []
  invalidation_triggers: []

The fields describe more than a happy path. Preconditions tell the router when the procedure is eligible. Inputs and outputs make composition possible. Side effects and permissions constrain what execution may change. Invariants state what must remain true, while the environment fingerprint ties the result to relevant tool, repository, policy, and runtime versions.

The remaining fields carry the capability’s scar tissue. Known failure modes record bad conditions and divergence signals. Counterexamples include cases where a tempting shortcut fails or where the base model performs better without the capability. Invalidation triggers identify changes that should quarantine the capability, and the expected cost lets the router compare a specific procedure with a safer or cheaper alternative.

This explicit failure surface prevents a reliable local procedure from being applied too broadly. It should also state when to abort, when to escalate, and what evidence is required before a side effect continues. Negative knowledge is often the most valuable part because it keeps yesterday’s success from becoming tomorrow’s automatic mistake.

Capabilities belong in a typed graph

A flat skills directory treats retrieval as the main problem: find a plausibly related file and put it in context. A capability graph treats selection as a constrained decision. Its edges can say that one capability specializes or generalizes another, depends on a tool adapter, supersedes an older version, conflicts with a policy, composes with a verification step, costs less, is safer, was derived from a set of episodes, or was invalidated by an environment change.

Runtime selection then resembles overload resolution in a programming language. The router chooses the most specific capability whose preconditions are satisfied, whose permissions fit the task, and whose evidence predicts a positive result in the current environment. If two candidates remain plausible, the system should expose the ambiguity, choose a bounded fallback, or ask for review instead of blending instructions and hoping they agree.

This graph also changes deduplication. Two similar procedures should not be merged because their prose looks alike. The curator should extract a shared behavioral core, preserve context-specific adapters, and replay every originating case against the proposed replacement. Only then can the graph mark the originals as superseded.

The same ownership question applies across organizational boundaries. An implementation partner can accumulate general delivery capabilities while the customer needs the tests, adapters, operating context, and recovery paths required to run its own workflow. Our essay on forward-deployed engineering handoffs examines that division from the buyer’s side. A private capability graph makes the division concrete because dependencies and operating evidence have named owners.

The source of truth should be the experience and capability graph

Human-readable harness roots are useful because models and people need a compact working set. They become dangerous when they are treated as authoritative records. A root is a materialized view generated for the current project and task, much like a database view generated from underlying records.

The authoritative layer should be an event-sourced experience and capability graph. “Event-sourced” means the system preserves the sequence of tasks, environments, decisions, artifacts, outcomes, dependencies, evaluations, versions, promotions, and rollbacks that produced the current state. The current graph can then be rebuilt, inspected, or rolled back without pretending that the latest summary contains the whole history.

A generated root should contain only the active working set: validated capabilities relevant to the project, current context and invariants, known failures, approved tool adapters, and quarantined candidates that need review. Summaries, indexes, and root files are build artifacts. Regenerating one should not erase the observations or decisions from which it was built.

This requires a cognitive build system with explicit dependency edges. A repository file may support a subsystem model; that model may support an architecture summary; the summary may feed a deployment capability; the capability may appear in a release checklist. If the repository file changes, dependency hashes should invalidate only the downstream beliefs and capabilities that relied on it.

Raw observations act as source files. Summaries act as object files, validated capabilities as linked executables, and the root as build output. The analogy is useful because it forces the system to preserve provenance and rebuild boundaries. Retrieval can find a relevant summary, but retrieval alone cannot determine which conclusions became false when one supporting fact changed.

Safe abstraction starts with independent rediscovery

A new capability should begin close to the experience that produced it. Local scope limits damage and keeps the environment assumptions visible. Promotion should follow a progression from ephemeral to personal to project to organization to ecosystem, with stronger verification, permission review, and redaction at every transition.

Repeated independent rediscovery is useful evidence for a higher abstraction. When separate workers produce behaviorally similar procedures for different cases, the compiler can cluster them, propose a shared core with context adapters, and replay every originating case. Promotion follows only if the shared version preserves the correct results and the adapters preserve the meaningful differences.

This is safer than asking a model to generalize after one success. It also gives the organization a way to renormalize experience over time: raw event → episode → recipe → capability → workflow motif → organizational policy. Each level preserves the details that remain predictive at its scale and drops details that do not help future decisions.

A mature capability approaches a fixed point. New examples sharpen its preconditions, counterexamples, and cost estimate without repeatedly rewriting the central procedure. Constant core rewrites are a sign that the abstraction is premature, the environment is unstable, or several capabilities have been collapsed into one.

Operational motifs let capabilities compose into real work

The reusable unit above a skill is an operational motif: a recurring state machine for resolving a class of work across different tools and business objects. One common motif is detect discrepancy → gather evidence → normalize facts → compare against policy → choose remediation → execute → verify → monitor.

That sequence can organize deployments, invoices, access problems, complaints, insurance claims, compliance exceptions, and subscriptions. The shared runtime manages state, evidence, policy comparison, approvals, execution, and recovery. Domain semantics enter through adapters that know what an invoice, entitlement, deployment, or claim means and which actions are permitted.

A simple grammar makes the layers easier to distinguish. Tools are verbs, business objects are nouns, skills are phrases, and motifs are grammatical productions that assemble phrases into a valid process. The harness is the generated program for the current task. This model lets a system reuse case-resolution structure without pretending that a billing dispute and a failed deployment carry the same policy or consequence.

Motifs also create a practical boundary for human review. A person can approve the policy comparison, remediation class, or side effect without rereading every tool instruction. If verification fails, the runtime returns to a named state instead of improvising a new process inside an opaque conversation.

Agents need institutional roles around admission and decay

A compounding system needs logical roles even when several roles run in the same service. The worker proposes a solution from the current task, while the compiler generalizes and packages candidate lessons. The verifier tries to break those candidates, and the curator resolves overlap, conflicts, and abstraction boundaries.

A policy gate decides which scope and permissions a capability may receive. A maintainer watches telemetry and environment drift; a garbage collector retires low-value, stale, or dominated artifacts; and an auditor reconstructs why a candidate was promoted or rolled back. These are separations of responsibility, not a requirement to deploy eight conversational agents.

The creator cannot be solely responsible for admission. Otherwise a mistaken inference can become a durable instruction, generate more outcomes that follow the mistake, and then cite those outcomes as confirming experience. Visible evidence, bounded permissions, independent verification, rollback, and named ownership interrupt that loop.

Mature automation should erase its own interface

The product consequence is self-erasing software. The first occurrence of a task family may be human-led with AI assistance. A later occurrence can become AI-led with confirmation, then autonomous with review, and eventually silent execution with exception reporting when the evidence and consequence justify it.

The interface shrinks because ordinary cases stop needing conversation. What remains visible is the training surface for new cases and the exception surface for cases near a boundary. This progression should happen capability by capability, not through a general autonomy setting.

The operating promise is to avoid solving the same class of problem from scratch twice. If the architecture works, models become replaceable workers behind a customer’s private, validated capability graph. The durable advantage sits in the accumulated procedures, negative knowledge, adapters, dependencies, evaluations, and operating history that encode how the organization actually resolves work.

Benchmark the sequence, not the isolated task

Single-task benchmarks ask whether an agent can complete a task under a fixed setup. A compounding harness needs an amortization benchmark that repeats a task family and measures whether prior experience changes later runs. The test should hold the acceptance bar steady while allowing the harness to create, select, revise, or retire capabilities between occurrences.

For occurrence n, record C_n, the token, compute, and tool cost expressed in a common cost unit; H_n, the number of human interventions; and E_n, an error-or-rollback indicator for that occurrence. Also record T_n, elapsed time; M_n, capability creation, verification, and maintenance cost allocated to that occurrence; and A_n, artifact ambiguity, measured as the number or weighted plausibility of competing capabilities the router considered applicable.

A useful cost comparison includes the factory tax. Lower direct inference cost does not count as compounding if maintenance expense grows faster than the work it saves. Likewise, fewer human interventions do not count as progress if errors rise or reviewers lose the evidence needed to detect them.

For a sequence of N occurrences, let B_n be the estimated total cost of occurrence n without capabilities learned on earlier runs and K_n be its actual total cost. Express both in the same monetary or normalized cost unit and include every cost each path incurs. K_n must include direct execution, human labor, allocated creation, verification, maintenance, and failure or recovery costs; B_n must include the corresponding baseline execution, labor, and failure or recovery costs.

LCR_N = [Σ(B_n) - Σ(K_n)] / Σ(B_n), for n = 1 … N

A positive LCR_N shows compression for the measured sequence. It does not prove that the capability will retain its value in a changed environment.

Artifact count is another constraint. A healthy system should let tasks grow much faster than admitted capabilities because shared cores and adapters absorb repeated structure. Artifact Entropy is a weighted measure of overlap, conflict, staleness, and weak differentiation across the capability graph. High entropy appears at runtime as rising A_n: several plausible skills compete, the router spends more intelligence choosing among them, and small wording differences hide the absence of a clear boundary.

A compounding result should show C_n, H_n, and T_n trending down across repeated cases while the aggregate error and rollback rate derived from E_n does not rise. M_n should fall after the initial investment and remain below the savings it enables; artifact count should grow far more slowly than completed tasks, and ambiguity should stay bounded or fall as the graph matures. That sequence is the evidence for capability yield.

The benchmark question is direct: after encountering this task family before, did the system become measurably cheaper, faster, and more reliable? If the answer cannot be reconstructed from telemetry, tests, promotion history, and outcomes, the organization has accumulated artifacts without proving that it learned.

Start with one recurring workflow

Choose one task family with enough repetition to compare later runs against a stable baseline. Measure direct cost, human intervention, elapsed time, errors, maintenance, and selection ambiguity; then admit only the capabilities whose savings survive verification and counterexamples.

BaristaLabs can help evaluate that sequence through AI consulting. Bring one recurring workflow, its recent traces, and the result your team considers acceptable. The next decision is whether repeated runs are actually becoming cheaper, faster, and more reliable.