Capstone: the full ops agent

Walk it top to bottom and say, for each layer, what breaks without it - that is the lever diagnosis habit from b1 turned into an architecture review:

• No input guardrail - the agent burns budget on off-topic or unsafe asks.
• No planner - complex tasks get one-shot, half-done answers (the 10/12 rung never arrives).
• No toolbox - fluent, confident, invented numbers (the b1 "demo that lied").
• No memory sidecar - multi-step findings fall out of context (stuck at 5/12).
• No output/approval layer - injected instructions in tool results get obeyed, and emails go out unapproved.
• No eval gate, no tracing - you cannot prove any of the above, before or after shipping.

OpenAI's guide reduces every agent to model, tools, instructions; Anthropic's essay demands simplicity and transparency. This diagram is both, with the guardrails drawn where they actually sit.

The monthly ops report never changes shape: numbers vs last month, refunds, subscription changes, one action. In b3 you built it as a prompt-chained workflow around the server's monthly_report prompt - predefined code path, cheap, testable. The assembled agent routes that request straight to the workflow instead of looping.

This is Anthropic's core rule surviving into your architecture: use the agent only where the task is too varied for a fixed path. An agent that also knows when NOT to be an agent is the mark of a builder who read the essay.

The assembled agent is smaller than you expect. One config dict declares every lever; one loop runs them in order. This is the skeleton you flesh out tonight:

CONFIG = {
    "model": "claude-opus-5",
    "tools": DATA_TOOLS + ACTION_TOOLS,           # b2: the 6-tool MCP toolbox
    "max_turns": 15,                              # b1: loops need exits
    "budgets": {"tool_calls": 25, "usd": 0.50},   # b7: stop conditions
    "high_risk": ["send_email", "refund_order"],  # b7: approval-gated
}

def run_ops_agent(goal: str) -> str:
    plan = make_plan(goal, CONFIG)                   # b5: plan-then-execute
    messages = [{"role": "user",
                 "content": f"{goal}\n\nPlan:\n{plan}"}]
    for _ in range(CONFIG["max_turns"]):
        reply = client.messages.create(
            model=CONFIG["model"], max_tokens=1024,
            tools=[t.schema for t in CONFIG["tools"]],
            messages=messages,
        )
        if reply.stop_reason != "tool_use":
            return screen_output(reply)              # b7: output check, then done
        for call in tool_uses(reply):
            spend_budget(call, CONFIG["budgets"])    # b7: budget guardrail
            raw = execute(call)                      # b2: toolbox does the touching
            safe = screen_injection(raw)             # b7: wrap TOOL RESULTS
            if call.name in CONFIG["high_risk"]:
                safe = hold_for_approval(call, safe) # b7: gate the SEND
            messages.append(tool_result_block(call, safe))
        messages = compact_if_needed(messages)       # b4: memory
    return "Max turns hit - escalating to a human."  # b1: exit, never a hang

Every commented line points at the session that built it. If a line surprises you, that session's cheat sheet is your fix.

Everyone who assembles this hits the same two bugs. Both are placement errors, not logic errors:

• Bug 1: the injection screen wraps the wrong thing. Screening only user input feels natural - that is where attackers type, right? Wrong. The tickets scenario's attack arrives inside a list_tickets TOOL RESULT: untrusted customer text flows into context through a tool the agent trusts. The screen must wrap tool results, or the trap walks straight past it.
• Bug 2: the approval gate holds the wrong step. If the gate blocks the DRAFT, the agent never produces the email, the human has nothing concrete to review, and the visible catch that makes approval meaningful disappears. Hold the SEND: let the agent draft freely, then stop the one outward, hard-to-reverse action for a human yes.

Check both placements in your build before you run the gate - they are the difference between 12/12 and a 10/12 that looks mysterious.