Stratum Praxis · Field Guides
AGENT OPERATIONS · DECISION GUIDE

AI agent economics and governance belong on the same screen.

An agent is not operationally ready because it can complete a demo. Before scale, make cost per successful outcome, retry behavior, human review, authority and rollback visible together.

1. Measure cost per successful outcome, not cost per model call

A cheap model request does not create a cheap agent if the workflow retries repeatedly, fails often or needs heavy human review. The useful unit is the cost of a successful business outcome after all execution, tool, review and fixed operating costs are included.

EXECUTIONModel + tools

Cost of each attempt and connector call.

RETRYExtra attempts

Loops and retries increase real unit cost.

FAILURELost outcomes

Final failure changes cost per success.

REVIEWHuman time

Approval and exception handling are operating cost.

Start here: the free AI Agent Economics Calculator models these components separately so a low token bill cannot hide expensive review or failure.

2. Track retries as an operating signal

Retries are not only a reliability metric. They affect cost, latency and the probability that an agent drifts into a sequence the team did not intend. Set an explicit retry ceiling, define what happens when it is reached and measure whether specific tasks produce repeated failure patterns.

If an agent needs several attempts for a task that a human completes predictably in one pass, the economics may still work — but only if the total cost and risk remain acceptable. The decision should use the whole path, not a single successful demonstration.

3. Put authority boundaries next to capability

Capability answers “what can the agent do?” Governance answers “what is the agent allowed to do without another authority?” Those are different questions. Define which actions can run automatically, which require human approval, which must be logged and which should never be available to the agent.

ControlQuestionExample boundary
PermissionWhat systems and data can it access?Read customer records, but no bulk export.
ActionWhat can it change?Draft a refund response, but human approves payment.
BudgetHow much cost can it incur?Execution cap per task and per day.
RetryHow many attempts are allowed?Stop and escalate after a defined ceiling.
LoggingWhat evidence is retained?Record action, input source and decision state.
RollbackHow is damage contained?Reversible change or human recovery path.

4. Human review is not a failure of automation

Some workflows become more valuable when an agent handles repetitive preparation and a human keeps judgment, authority or exception handling. The correct design goal is not always zero human involvement. It is the smallest human checkpoint that keeps risk legible without destroying the economics.

The Agent Control Auditor exists to separate useful autonomy from uncontrolled authority. A strong system can say “human required here” without treating that as an implementation defect.

5. Keep the operating layer portable

Model and runtime choices change faster than business policy. Avoid placing every rule, skill and operating assumption inside one vendor-specific prompt or interface. Keep operating intent, policy, reusable skills and state as explicit layers so the organization can move between runtimes without rebuilding governance from scratch.

BRAINOperating intent

Goals, context and durable decision logic.

POLICYBoundaries

Authority, approval and cost controls.

SKILLSActions

Reusable capabilities with defined contracts.

STATEContext

Portable working memory and handoff state.

The Cross-Agent Operating Kit is the paid operating layer for this problem. It should follow economics and control checks, not replace them.

6. Define the stop conditions before scale

Scale decisions need explicit failure conditions. Stop or redesign when retry rate rises beyond the approved ceiling, human review expands faster than value, failures cannot be surfaced quickly, data or authority boundaries become unclear, or cost per successful outcome no longer supports the business case.

Useful scale sequence

  1. Model unit economics with realistic retries and review.
  2. Map permissions, human gates, budget limits and rollback.
  3. Run a bounded pilot with logs.
  4. Compare observed economics with the planning baseline.
  5. Scale only the tasks that remain economical and controllable.

7. Re-verify after the runtime or workflow changes

Agent systems drift when models, prompts, integrations, policies or workflows change. Treat economics and governance as recurring checks rather than a one-time launch document. When the runtime changes, rerun cost and control checks. When permissions expand, revisit human gates. When a task becomes more complex, recalculate successful-outcome economics.

Make the agent legible before you make it autonomous.

Start with economics, then authority. Use a paid operating layer only when the free evidence says the system is worth operating.

Decision support only. Validate security, permissions, privacy and production performance for your own environment before deployment.