Engineering Production Agentic Systems: Part 3: The Topology

Human-in-the-Loop Topology for Production Agentic Systems — Loop Bounding, Approval Gates, and Termination Discipline

This is Part 3 of a three-part field manual on engineering production agentic systems. Part 1 took context engineering. Part 2 took guardrails. This part takes human-in-the-loop topology and closes the series. The conviction underneath all three: production agentic systems are won on these three architectural disciplines — not on model choice.

The Opening Claim

Almost every conversation I have with teams designing agentic systems eventually arrives at the same wrong question: “Should we have a human in the loop?” The answer is yes, always. That is not the design question. The design question is “At which joints, with what context, and with what default behavior on timeout?”

The right HIL topology is what separates an agentic system that can run autonomously under regulated-industry scrutiny from one that produces impressive demos and falls apart on the third Tuesday in production. The wrong HIL topology is one of two failure modes: humans approving every action (which kills the leverage agents are supposed to provide), or humans approving nothing (which surfaces every failure mode of unbounded agent execution).

The agent-loop divergence failure mode I named in Part 1 is what HIL topology exists to prevent. The agent reasoning loop, left unbounded, generates plausible-but-wrong subgoals that compound across turns. Turn three produces a subgoal that should have been rejected at turn two. Turn five calls a tool whose preconditions don’t actually hold. Turn nine returns a confident output that’s structurally broken. The fix is not “give the agent better instructions.” The fix is explicit loop topology: agent reasoning bounded by deterministic logic, with human approval at the joints, and three independent termination conditions.

This part is about how the topology gets built. Five HIL joint types, each with its purpose and default. Three termination conditions, each independent. One closing feedback loop that turns approvals into a training signal. And the multi-agent extension where humans become handoff points between agents as well as gates over actions.

The Loop Bounding Problem

The cheapest failure mode in agentic systems is also the most common: an agent loop that doesn’t know when to stop. The agent generates a plan, executes a step, evaluates the result, generates a new plan, executes a step, and so on. Each iteration looks locally plausible. The aggregate trajectory drifts.

Three things produce loop divergence. First, compounding confidence error — the agent rates its own intermediate outputs as confident, and that confidence does not decay across turns even when the cumulative evidence should reduce it. Second, subgoal generation pressure — when no progress is being made on the primary goal, the agent invents plausible-sounding sub-problems to work on, none of which actually advance the task. Third, tool-call habit — if a tool is on the surface, the agent will eventually find a reason to call it, even when the right action is to stop and ask.

There are three bounding techniques that work in production, applied together rather than in isolation. The first is explicit max-turn budgets — every agentic task has a maximum number of loop iterations defined at task initiation, often shorter than teams initially think (a typical resolution-planning task should resolve in five to seven turns, not twenty). The second is deterministic intermediate validators — after every plan-step output, a non-LLM check verifies the plan still aligns with the original task; if it doesn’t, the loop terminates and escalates. The third is joint-by-joint state machines — the loop doesn’t free-run from start to end; it traverses an explicit state graph where each transition is approved either deterministically or by a human.

The first technique is cheap. The second is mid-cost. The third is the most expensive to design but also the most defensible — and the one that makes the HIL joints from the next section actually work.

HIL Joints as a Design Vocabulary

A joint is a position in the agent loop where a human can intervene. Not “could intervene if a flag is set” — will be involved under the conditions the joint specifies. Five canonical joint types, each with its own purpose, context shape, and default behavior on timeout.

The Agent Loop With HIL Joints

Joint 1 — Planning Approval

Trigger: a high-stakes task that requires committing to a strategy before any tool is called. The agent produces a plan; the human approves, edits, or rejects the plan before the agent is allowed to act on it. Context shape: the full proposed plan, the alternative plans the agent considered, and the reasoning trace for the chosen path. Default on timeout: hold; expire after a configurable window and queue for batch review.

Joint 2 — Parameter Approval

Trigger: a tool with bounded but tunable parameters where the agent’s proposed value falls outside the “soft” range (the range that wouldn’t require approval) but inside the “hard” range (the range that’s allowed at all). Context shape: the tool name, the proposed parameters, and the policy band. Default on timeout: hold; the human edits parameters into the soft range or rejects the call.

Joint 3 — Action Approval

Trigger: any cost-reversible or irreversible action, per the reversibility matrix from Part 2. This is the most expensive joint, the one the matrix from Part 2 governs in detail. Context shape: the proposed action, its reversibility class, its expected impact, and the precise tool contract being invoked. Default on timeout: hard block — no fallback action runs; the loop pauses indefinitely until a human responds. This is the only joint where indefinite pause is the correct default.

Joint 4 — Post-Hoc Review

Trigger: a sample of actions of risk-class X, or all actions in audit-required regimes. Context shape: the full event from the audit trail. Default behavior: the action ran; review is queued; if rejected, a rollback or remediation event is emitted. This is where compliance pull-review lives.

Joint 5 — Escalation

Trigger: the agent’s self-assessed confidence drops below the floor (typical floor is ~0.45 on the calibrated scale), or the same subgoal fails twice in a row, or a deterministic validator flags a plan-step misalignment. Context shape: the full trajectory so far, the trigger reason, and the current state. Default: halt; request human takeover; the agent does not retry without explicit human re-engagement.

A snippet showing the joint registration:

# Pattern — joint registration at task initialization
task = AgentTask(
    goal="resolve_supply_chain_exception",
    joints={
        "plan_approval":   Joint(trigger="every plan with risk≥medium",
                                  context="plan + alternatives", default="hold"),
        "param_approval":  Joint(trigger="param outside soft-band",
                                  context="tool + params + band", default="hold"),
        "action_approval": Joint(trigger="risk×reversibility matrix",
                                  context="action + impact", default="HARD_BLOCK"),
        "escalation":      Joint(trigger="confidence < 0.45 or subgoal_repeat",
                                  context="full trajectory", default="HALT"),
    },
    termination=TerminationPolicy(max_turns=12, cost_ceiling="$5.00",
                                    confidence_floor=0.45),
)

The discipline here is that joints are registered at task initialization, not improvised at runtime. The agent doesn’t get to decide when a human gets involved; the topology decides.

Context for the Human

The human at a joint is themselves a context consumer. This is the point where the Role Adapter from Part 1 reappears: the Supply Chain Manager at the planning approval joint needs different context than the Logistics Analyst at the assessment joint. The pipeline doesn’t just produce context for the agent; it produces context for the humans who gate the agent.

This is the architectural payoff for treating context as a managed pipeline. The same Role Adapter that produces the agent’s view of a hierarchical context tree also produces the human’s view. Different role, different subtree, same underlying data model. The Supply Chain Manager at Joint 3 — action approval for a reroute_container call — sees the proposed action, the cost impact, the customer impact, the SLA implications, and a short rationale chain. They do not see the agent’s full reasoning trace, the alternative plans considered, or the retrieval scores — that’s too much context for the decision the human is being asked to make.

The right context for a HIL decision is the minimum context that supports a confident yes-or-no. Not the full trace; not the executive summary; the slice that’s specific to the joint type and the role. Teams that get this wrong tend to default to one of two failure modes: too much context (the human becomes a copy-edit pass over the agent’s full reasoning, which kills the leverage), or too little (the human is asked to approve an action they can’t actually evaluate, so they approve everything, which kills the safety).

A practical rule: the context delivered at a HIL joint should be readable in under thirty seconds and decidable in under sixty. If the human at the joint can’t make a confident decision in that envelope, the joint is wrong — either the joint should be earlier (so less context is needed), or the agent should be doing more upstream work to make the decision tractable.

The escalation joint (Joint 5) is the exception. When confidence drops or subgoals repeat, the human takes over the whole problem; they need the full trajectory. The expected human action there is not approve-or-reject; it is resume-and-redirect. Context shape is correspondingly richer.

Termination Conditions

The cheapest defense against agent-loop divergence is three independent termination conditions composed in AND-not-OR. Any single one of them breached, the loop terminates immediately.

Termination Conditions — Three Independent Floors

Cost Ceiling

A budget on the total token spend, API call count, or dollar cost the loop is permitted to incur. Set at task initialization based on the task’s expected value. A routine status update should not exceed five turns’ worth of cost; a complex multi-stage resolution might cost the equivalent of fifteen turns. The ceiling is the budget, not the expected spend; breach it, and the loop terminates regardless of state.

Turn Limit

A hard maximum on loop iterations. This is the simplest and most underused failsafe. A typical task should resolve in five to seven turns; setting the limit at twelve gives the agent room to recover from one wrong path without removing the bound. Setting it at fifty defeats the purpose. The turn limit should be tight enough that hitting it surfaces a real problem, not lax enough that it’s a theoretical bound the agent never reaches.

Confidence Floor

The agent’s self-assessed certainty in its current trajectory, evaluated each turn. If the floor is breached, the loop terminates and the escalation joint fires. The floor’s calibration matters more than its absolute value — a confidence score of 0.7 from a well-calibrated agent means something different than 0.7 from a poorly calibrated one. The calibration is itself an artifact of the Evolution Layer’s feedback ingestion (next section).

# Pattern — per-turn termination check
def should_terminate(self, state: AgentState) -> Optional[str]:
    if state.cost_used >= state.cost_ceiling:
        return "cost_ceiling_breached"
    if state.turn_count >= state.max_turns:
        return "turn_limit_breached"
    if state.confidence < state.confidence_floor:
        return "confidence_floor_breached"
    return None

The composition matters. Any breach terminates the loop — three independent failsafes, not three redundant ones. A budget overrun without a turn overrun still terminates. A turn overrun with high confidence still terminates. The AND-not-OR composition is the discipline that makes the bound defensible. Teams that compose termination as “must breach all three” produce systems where one weak failsafe defeats the other two.

Feedback as the Closing Loop

HIL approvals are not just gates. They are a training signal. Every joint decision — approved, edited, rejected — is data the system can use to retune itself. The Evolution Layer from Part 1 is the architectural seam where this loop closes.

A snippet from the repo’s evolution module showing the feedback ingestion path:

# From context_evolution.py — feedback ingestion (abbreviated)
def collect_feedback(self, exception_id, process_step, feedback_type,
                      feedback_value, metadata):
    feedback = {
        "exception_id": exception_id,
        "process_step": process_step,
        "feedback_type": feedback_type,    # approval | rejection | edit
        "feedback_value": feedback_value,  # signal magnitude in [0, 1]
        "timestamp": datetime.utcnow().isoformat(),
        "metadata": metadata,              # role, joint type, edit diff
    }
    self.store.append(feedback)
    # Asynchronously: update fusion alpha, landmark selection,
    # role-adapter pruning, and termination thresholds.
    self.adapt_strategies(feedback)

Three things to defend about this design.

Approvals are first-class feedback, not just events. When a human approves a plan unchanged, that is a positive signal — the plan was on the right path; the agent’s strategy is working. When a human edits parameters before approving, that is a corrective signal — the strategy is approximately right, but the parameter selection needs tuning. When a human rejects an action, that is a strong negative signal — the strategy itself is wrong. The Evolution Layer reads these three as different update magnitudes on different strategy parameters.

Feedback adjusts the pipeline, not just the model. The retuning targets are pipeline-layer parameters: the fusion alpha in Gather, the landmark selection in Compress, the role-adapter pruning in Enrich, the termination thresholds in Topology. Models do not get retrained inline; pipelines do. This is what makes the loop affordable to run continuously.

Feedback runs asynchronously to the action path. The agent acts; the human approves; the action commits. The feedback ingestion runs after commitment, on a separate path, so retuning never blocks live execution. This is the same separation that lets financial trading systems retrain risk models without slowing the order-placement path.

The closing loop runs continuously. Every HIL approval, every rejection, every edit becomes signal. The pipeline’s strategy parameters drift toward the choices humans make. Over time, the joints fire less often because the agent’s first-pass plans match what humans would have edited toward. This is what “the system learns” actually means in production agentic systems — not the model getting smarter, but the pipeline’s strategy parameters getting better calibrated to the workflow’s actual decision distribution.

Multi-Agent HIL Topology

When two or more agents collaborate to resolve a task, joints multiply. Inter-agent handoffs become their own joint type — sometimes deterministic, sometimes human-gated. The Cross-Process Memory Manager component from the Evolution Layer is the substrate that lets state pass cleanly across agent boundaries.

Two patterns I have seen work in production. The first is one-human-many-agents: a single human approver acts as the joint for multiple specialized agents (a research agent, a planning agent, an execution agent). The human sees the handoff context as the agents pass work between themselves; they only intervene when a handoff itself is high-stakes. The second is agent-as-reviewer: a senior agent (typically with stricter validation prompts and access to ground-truth verification) reviews the junior agent’s output before it reaches a human. This is the agentic-AI equivalent of a code review — one agent gates another before a human gates either.

Handoff Opacity — and How the Audit Trail Closes It

The trap in multi-agent HIL topology is handoff opacity. When work passes between two agents and the human doesn’t see the handoff, the human cannot identify which agent’s reasoning produced the eventual error. The fix extends the audit event schema from Part 2 with three handoff-specific fields:

{
  "event_id":      "evt_2026_05_12_h3a9c",
  "stage":         "orchestration.agent_handoff",
  "actor":         { "kind": "agent", "role": "planning_agent" },
  "handoff": {
    "from_agent":            "research_agent",
    "to_agent":              "planning_agent",
    "handoff_context_hash":  "sha256:c3a8...e91f",
    "handoff_reason":        "research_complete"
  },
  "prev_event_id": "evt_2026_05_12_h3a9b"
}

The handoff_context_hash is the key field. It hashes the context payload passed between agents at the moment of handoff, which means a post-hoc reviewer can verify what the receiving agent actually saw — not what the system claims it saw. Multi-agent systems without this discipline produce post-mortems where engineers spend hours reconstructing which agent had what context at what time; with the hash, the question is decidable in seconds.

Worked Example — Three-Agent Supply Chain Exception

In MoJoCo’s supply chain handling, a single exception traverses three specialized agents. The research agent gathers customer impact data, SLA terms, and alternative routing options; it has read-only tool scope. It hands off to the planning agent, which drafts two-to-three resolution options ranked by cost-and-customer-impact; it has read-only tool scope plus access to cost-modeling tools. Planning hands off to the execution agent, which has the operationally consequential tools — including reroute_container and notify_customer.

The handoffs are joints. Research → planning is deterministic (driven by research_complete signal). Planning → execution is human-gated — the Supply Chain Manager reviews the planning agent’s recommendation in the context the planning agent compiled, approves the selected option, and only then does the execution agent receive its task scope. This is also the seam where the reversibility matrix from Part 2 actually fires — the Supply Chain Manager’s approval at this joint is the dual-approve gate that the matrix requires for irreversible action.

Implicit Human Availability — The Scheduling Discipline

The second multi-agent trap is implicit human availability. Multi-agent systems often assume a human is always reachable for the rare joints that require approval; in regulated industries with global workflows, this is wrong by construction. The HIL topology has to account for explicit human shift coverage (which roles are on call at which hours, in which regions), escalation paths when the first-line approver is unavailable, and the default-on-timeout behavior at each joint.

The discipline that works: every HIL joint registers a coverage policy alongside its trigger — primary approver, secondary approver, tertiary approver, and a default action if all three are unreachable within the joint’s timeout window. Follow-the-sun coverage rotates the primary approver role through regional teams as the business day moves. None of this is glamorous; all of it is the difference between a multi-agent system that holds up at 03:00 on a Saturday and one that doesn’t. The topology design has to encode the scheduling from day one — adding it after the fact means retrofitting every joint’s default behavior, which is the kind of change that almost never gets fully completed.

Closer — The Moat Is Architecture

This is the closer of the series, not just of Part 3. The full argument is now defended.

Production agentic systems are won on context engineering, guardrails, and human-in-the-loop topology — not on model choice. Across the three parts, the engineering specifics that defend that claim:

The pipeline is five runtime stages (Gather, Enrich, Verify, Compress, Inject) composed with four architectural layers (Acquisition, Refinement, Distribution, Evolution) plus Orchestration. The pipeline produces role-calibrated, token-efficient context. It prevents context-window collapse.

The guardrails are five-field tool contracts (name, schema, scope, risk class, reversibility) enforced by the Function Identifier at injection time, an audit event schema emitted as a first-class artifact, and a reversibility-by-risk matrix that determines the HIL gate depth for every action. The guardrails prevent tool-authorization sprawl and audit-trail opacity.

The topology is five canonical HIL joint types (planning approval, parameter approval, action approval, post-hoc review, escalation), three independent termination conditions (cost ceiling, turn limit, confidence floor), and a closing feedback loop where approvals retune the pipeline’s strategy parameters. The topology prevents agent-loop divergence.

Models are commoditizing. The frontier-model gap on agentic benchmarks is shrinking quarter over quarter. The moat for enterprise agentic systems is not which model you call — it is the architectural disciplines at the context layer, the tool surface, and the HIL topology. These decisions determine the production outcome quality almost entirely. The model decision determines very little.

This is the pattern that underpins MoJoCo, the agentic modernization platform I have been designing hands-on for eighteen months. The deterministic reverse-engineering tools (ARC, MAM, CAST) provide the action surface. The pipeline produces reasoning-grade context above them. The guardrails filter and audit every action. The topology decides when the agent acts and when a human takes over. Four disciplines composed into one architecture. The same pattern recurs in the Digital Fitness Index (agentic tech-debt scoring) and AskProcurement (AI-native procurement intelligence). Different surface; same substrate.

If you are designing agentic systems in production right now, the question is not which model you should use. The question is which of these architectural disciplines you have not yet engineered. Most teams have not engineered any of the three. That is the opportunity. That is the moat.

References

Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L., Simens, M., Askell, A., Welinder, P., Christiano, P., Leike, J., & Lowe, R. (2022). “Training Language Models to Follow Instructions with Human Feedback.” OpenAI. NeurIPS 2022. The InstructGPT paper; anchors the feedback-as-training-signal claim and the discipline of treating approvals/rejections/edits as different magnitudes of corrective signal. arXiv:2203.02155

Bai, Y., Kadavath, S., Kundu, S., Askell, A., Kernion, J., Jones, A., Chen, A., Goldie, A., Mirhoseini, A., McKinnon, C., Chen, C., Olsson, C., Olah, C., Hernandez, D., Drain, D., Ganguli, D., Li, D., Tran-Johnson, E., Perez, E., … Kaplan, J. (2022). “Constitutional AI: Harmlessness from AI Feedback.” Anthropic. Closest published source for the agent-as-reviewer pattern referenced in the multi-agent HIL section; provides the discipline for one agent gating another before human review. arXiv:2212.08073

Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Liu, J., Awadallah, A. H., White, R. W., Burger, D., & Wang, C. (2023). “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework.” Microsoft. Foundation for the multi-agent HIL extension; defines the handoff patterns that the topology section builds the human-gating layer on top of. arXiv:2308.08155

Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). “On Calibration of Modern Neural Networks.” ICML 2017. Foundation for the confidence-floor termination condition; explains why a confidence score of 0.7 from a well-calibrated agent means something different than 0.7 from a poorly calibrated one. arXiv:1706.04599

This concludes the three-part field manual. Part 1 took the pipeline. Part 2 took the guardrails. Part 3 took the topology. Production agentic systems are won here.

A consolidated Part 4 — Further Reading & Research Lineage — collects the references across all three parts plus a cross-cutting reference and a note on what is deliberately not cited.

Ram Ravishankar is an IBM Distinguished Engineer serving as Chief Engineer. Four patents, member of the IBM Academy of Technology, $1B+ cumulative business impact across 200+ engagements on six continents.

He has spent the last eighteen months hands-on designing agentic systems for enterprise modernization in regulated industries — including MoJoCo (an agentic modernization platform wrapping deterministic reverse-engineering tools — ARC, MAM, CAST), the Digital Fitness Index for agentic tech-debt scoring, and AskProcurement for AI-native procurement intelligence.