Most agent teams over-invest in the planner and under-invest in the tool surface.
Right tools + staged inputs ≈ 80% of the work. Orchestration is the rest.
Agent smart but wrong? Audit tools and context before another planner loop.
Last failure: prompt change, or tool change?
A steering pack with twelve owners is a pack with none.
Accountability is the name in the box after the miss. Responsibility is who can change the process before the next one.
If those two names differ and nobody can say why, the review is theatre.
Who can stop next week's decision without a committee?
Most transformation programs do not fail from tool quality. They fail from a blank cell in the RACI.
RACI is boring on purpose. Responsible executes. Accountable owns the outcome — singular. Consulted is two-way before the decision. Informed is one-way after. The matrix is a defect log, not a slide.
The pattern we keep seeing: a successful demo, a glowing steering pack, then months of "we're aligning stakeholders." The work exists. The workflow does not, because Accountable is a committee and Responsible is whoever answered Slack last.
A useful kill question before the next phase-gate: if this goes wrong on a Thursday, whose name is on the incident, and are they allowed to change the process without a new pack?
If those are two different people and neither can answer, you do not have a program. You have a waiting room.
Where is the blank cell in your current RACI — Accountable, or the right to change the work?
Walk-away leverage is the only honest pricing mechanism in a transformation program.
If stopping the work has a political cost and continuing it does not, you are not buying a capability. You are funding a narrative.
Name the date you would shut it down, and who has the right to do it.
If that sentence is hard to write, the program is already captured.
Stopped hand-copying skills across coding agents. One folder. Skills + commands. Sync targets in config. Same idea as dotfiles.
If the stack can't inherit one playbook, I'm debugging folklore, not systems.
How many copies of the same skill still live on your machine?
Shipping agents on vibe-checks is how regressions hide until a customer finds them.
A model eval scores one output. An agent produces a trajectory: tool picks, arguments, branches, retries, then a final answer. Correct endings through wasteful, brittle, or hallucinated paths still fail in production. If you only score the last message, you are grading the press release, not the decision process.
What I actually measure before a change hits production:
- Task completion on a versioned ground-truth set drawn from real ops, not public benchmarks the base model may have seen.
- Trajectory quality: right tools, valid args, no invented parameters, step efficiency vs a sane minimum.
- Constraint adherence: did it stay inside the write set, policy, and risk tier?
- Cost and latency per successful task — a "win" that burned 40 calls is a product decision, not a free lunch.
- Safety spot-checks by humans after model, prompt, or tool-schema changes. Automated judges help; they are not a substitute for calibration against people.
The decision-science cut: evaluation is how you know whether judgment improved. No suite on prompt edit means you are hoping. No held-out domain set means you are demoing. No regression run on tool changes means last week's green path can go red silently.
LLM-as-judge is fine for open-ended work once you've scored it against humans. Contaminated public leaderboards are not your production distribution. Multi-agent systems need both unit trajectories and the composed workflow — inter-agent failures rarely show up in single-agent unit tests.
If the agent can spend money, change state, or answer a regulated question, vibe-check is not a release gate.
What still ships because "a few runs looked fine"?
Most "mysterious double charges" I see are not race-condition genius. They are missing idempotency on a path that always retries.
Networks drop responses. Clients time out. Queues redeliver. Agents re-call tools. At-least-once is the default universe. If your mutation isn't safe to run twice, every retry is a coin flip with a side effect.
Idempotency is simple to state: same logical request, same observable outcome, no matter how many times it lands. Engineering it is three boring pieces.
1. A client-generated key (UUID or deterministic hash) travels with the request.
2. The server claims that key atomically, executes once, stores the result.
3. Duplicates return the stored result — they do not re-run the side effect.
The hard cases are partial success: charge succeeded, response lost; email sent, worker crashed; webhook accepted, write never committed. Outbox + idempotent consumers beat "hope the network is nice." State-machine transitions that reject illegal moves are idempotent by construction. Upserts beat blind inserts. Auto-increment IDs are uniqueness, not dedupe.
Agent stacks make this worse. A tool that "creates invoice" without a key will happily create three when the planner retries. Treat tool side effects like payment APIs: key required, result cached, structured error if the key collides with a different payload.
If a write path can be retried — and in production it can — ship the key first. Debugging duplicates after the fact is more expensive than the table you didn't want to add.
Which mutation in your stack is still safe only on the happy path?
If "who owns this dataset?" still answers with a platform team and no domain product owner, you don't have a mesh. You have a shared drive with better tooling. Who can change the contract without a six-week ticket?
Central data teams don't fail from lack of talent. They fail when every domain's definition of "customer," "order," and "ready" still routes through one bottleneck that can't know the business.
Centralized ownership felt safer until every request sat in the same queue. Federated ownership feels riskier until you measure cycle time to a usable product — then the old model looks like a waiting room.
A confidence score that never changes the path is decoration.
High → auto. Medium → human. Low → block or escalate. If the number doesn't route, you built a dashboard, not a decision system.
Where does low confidence still ship as a normal answer?
Manual second-brain hygiene dies in a week. Mine compounds because agents own sort, search, and file gen.
I keep the thinking. The agent keeps the filing.
If upkeep isn't near zero, the vault is a graveyard with good intentions.
What still depends on you remembering to tidy?
Most AI portfolios fail the same way: a long list of "opportunities," zero shared scoring, and the loudest sponsor wins the next sprint.
I use a four-axis screen before anything gets a pilot budget. Not a deck ritual — a kill filter.
1. Strategic fit. Does this use case leverage a real advantage you already have (data, distribution, process ownership), or is it generic automation cosplay? "Everyone is doing agents" is not fit.
2. Value creation. Name the mechanism: cycle-time cut, error-rate drop, revenue unlock, risk avoided. If you cannot write the metric and the owner of that metric, you are funding a demo.
3. Resource efficiency. People, systems access, change-management load, ongoing eval cost. One-shot build cost lies. Self-sustaining value beats perpetual prompt babysitting.
4. Risk and uncertainty. Blast radius if the model is confidently wrong, data sensitivity, regulatory exposure, reversibility. High uncertainty is fine — unowned uncertainty is not.
Score all four. Weight by your actual strategy, not equal slices. Force a composite and a forced rank. The point is not precision to two decimals. The point is making tradeoffs legible so "interesting" stops beating "important."
I have seen large enterprise programs approve ten pilots with no axis-3 or axis-4 pass. Six months later every pilot is "promising" and none is production-shaped.
If your opportunity list cannot survive a one-page four-axis score, you do not have a roadmap. You have a wish list.
Which active AI bet would fail axis 2 or 4 if you scored it honestly this week?
Most production agent bugs I debug are not "the model was dumb." They are unstructured text leaking into a typed boundary.
You asked for a decision object. You got a paragraph with a JSON-ish blob, a trailing apology, and a field name that almost matches the schema. Downstream code fails softly, retries burn money, and someone blames the planner.
Three enforcement strategies, ranked by how much I trust them:
1. Tool / function calling with a real JSON Schema. Constraint at generation time. Best when the API supports it. The schema is both contract and capability declaration for agents.
2. JSON mode / response_format. Valid JSON, weaker structure. Fine for flat extraction if you reinforce the shape in the system prompt. Nested optional fields still drift.
3. Generate free text → parse → validate → retry. Works with any model. Libraries that feed schema validation errors back as correction prompts make this sane. Cost is latency and a retry budget you must actually set.
Practical defaults I use: a typed schema as the source of truth for fields and errors. Prefer tool calling for agent dispatch. Keep schemas flat, enum-heavy, ≤ a handful of fields. Treat parse failure as a first-class outcome with a max retry count and a human/safe fallback — not an infinite loop.
If your agent stack still does naive JSON parsing on free-form completions without a schema and a retry policy, you do not have an orchestration problem. You have an interface problem.
Which boundary in your pipeline still accepts "probably JSON"?
If your AI standards live only in a signed PDF, you do not have governance yet. You have a document. Which principle still has no CI check, registry field, or owner?
Enterprise AI "governance" too often means a PDF, a steering committee, and a deck that never touches the deploy path. Principles without artifacts are theater.
Governance that ends at launch is incomplete. Drift, bias monitors, and anomaly alerts need named escalation and a path back into retraining and policy revision.