Production agent systems fail at three distinct layers: technical guardrails that prevent bad outputs, human collaboration patterns that prevent rejection, and autonomy calibration that prevents over-constraint or under-verification. The Midwest AI Summit (October 29, 2026) delivered three practitioner talks that map this stack end to end.
Heidi Porter covered evaluation and guardrail architecture for reliable workflows. Kevin Solorio described frontline worker collaboration models that earn trust instead of triggering pushback. Chris Shinkle and Andrew Dunlap presented an autonomy-level framework that maps verification needs to agent capabilities. Together, these talks expose the plumbing decisions that determine whether agents ship or stall.
Where Guardrails Execute in the Workflow
Guardrails are not a single checkpoint. Porter’s architecture places them at three distinct boundaries:
Pre-LLM call: Input validation catches malformed requests, out-of-scope queries, and prompt injection attempts before tokens burn. This layer enforces schema contracts and domain constraints.
Post-generation: Output guardrails verify factual accuracy, tone compliance, and format correctness. This is where hallucination detection, citation verification, and policy alignment happen.
Tool invocation boundaries: Before an agent calls an external API, database write, or file operation, a guardrail evaluates the proposed action against permission models and risk thresholds. This prevents cascading failures and unauthorized state changes.
The key insight: guardrails are not bolted on after the fact. They are part of the execution path, with distinct responsibilities at each stage. A financial workflow might allow creative language generation but hard-block any tool call that moves money without human approval. A code-generation agent might permit experimental refactors but require review before merging to main.
Evaluation Harnesses for High-Stakes vs. Iterative Workflows
Evaluation strategies diverge sharply based on failure cost and recovery speed.
| Workflow Type | Eval Focus | Verification Cadence | Rollback Strategy |
|---|---|---|---|
| Financial (high-stakes, auditable) | Correctness, compliance, audit trail | Pre-commit, synchronous | Hard block, manual override required |
| Software tasks (iterative, recoverable) | Utility, code quality, test coverage | Post-commit, async | Automatic revert, fast iteration |
| Customer-facing content | Brand alignment, tone, factual accuracy | Staged review, batch | Human approval gate |
High-stakes workflows demand synchronous verification before state changes. Iterative workflows tolerate async evals and fast rollback. The architecture difference is not just timing but also the shape of the feedback loop. Financial evals produce binary pass/fail signals. Software evals produce scored suggestions that inform the next iteration.
Human-in-the-Loop as a Feedback Trigger, Not a Bottleneck
Solorio’s “build with, not for” model translates into concrete infrastructure decisions. The failure mode is treating human review as a final approval gate that slows every decision. The correct pattern is treating human feedback as a retraining signal that improves agent autonomy over time.
Feedback loop mechanics:
- Agent proposes an action
- Human reviews and either approves, rejects, or modifies
- Rejection or modification triggers a labeled example that feeds back into the eval dataset
- Agent fine-tunes or adjusts its decision boundary based on accumulated feedback
This requires instrumentation at every human touchpoint. When a frontline worker overrides an agent’s recommendation, the system must capture:
- The original context and agent reasoning
- The human’s corrected decision
- The rationale (if provided)
- Metadata about the worker’s role and expertise level
Without this capture layer, human-in-the-loop becomes a permanent bottleneck. With it, the loop becomes a training harness that gradually expands agent autonomy.
The Autonomy-Level Framework as a Decision Tree
Shinkle and Dunlap’s framework maps agent independence to three variables: goals, constraints, and verification capabilities. This is not a maturity model where every team climbs the same ladder. It is a decision tree where different tasks demand different autonomy levels.
Level 1: Suggestion mode
- Agent generates options
- Human selects and executes
- Verification: human judgment
- Use case: exploratory analysis, creative brainstorming
Level 2: Supervised execution
- Agent executes with human approval gates
- Human reviews before commit
- Verification: automated checks + human review
- Use case: code generation, content drafting
Level 3: Autonomous execution with monitoring
- Agent executes independently
- Human monitors dashboards and alerts
- Verification: automated evals + anomaly detection
- Use case: routine operations, data pipelines
Level 4: Autonomous execution with post-hoc audit
- Agent executes without pre-approval
- Human audits logs periodically
- Verification: comprehensive logging + compliance checks
- Use case: high-volume, low-risk transactions
The key decision: what constraints and verification capabilities does your team actually have? A team with strong test coverage and fast rollback can safely operate at Level 3 for code changes. A team without automated compliance checks must stay at Level 2 for financial workflows, regardless of agent capability.
Swarm Coordination and Shared State Requirements
Shinkle’s forthcoming book The Art of Swarming addresses “emergent unified embodied intelligence” in multi-agent systems. At the infrastructure level, this requires:
Shared state management: Agents must read and write to a common state store with conflict resolution. Options include CRDTs for eventual consistency, distributed locks for strong consistency, or event sourcing for audit trails.
Consensus protocols: When agents disagree on the next action, the system needs a tiebreaker. This can be voting (majority rule), hierarchical (lead agent decides), or utility-based (highest expected value wins).
Coordination overhead: Every additional agent increases communication cost. A three-agent swarm has three pairwise channels. A ten-agent swarm has 45. The architecture must either limit swarm size or implement hierarchical coordination where agents report to coordinators instead of broadcasting to peers.
The failure mode: assuming swarms self-organize without explicit coordination primitives. The reality: without shared state, consensus rules, and bounded communication overhead, swarms devolve into independent agents that duplicate work or conflict.
Code Example: Guardrail Execution at Tool Invocation
class ToolInvocationGuardrail:
def __init__(self, risk_threshold: float, approval_required: bool):
self.risk_threshold = risk_threshold
self.approval_required = approval_required
def evaluate(self, tool_call: dict, context: dict) -> dict:
"""
Evaluate tool call before execution.
Returns: {"approved": bool, "reason": str, "requires_human": bool}
"""
risk_score = self._calculate_risk(tool_call, context)
if risk_score > self.risk_threshold:
return {
"approved": False,
"reason": f"Risk score {risk_score} exceeds threshold {self.risk_threshold}",
"requires_human": True
}
if self.approval_required and not context.get("human_approved"):
return {
"approved": False,
"reason": "Human approval required for this tool",
"requires_human": True
}
return {"approved": True, "reason": "Passed guardrails", "requires_human": False}
def _calculate_risk(self, tool_call: dict, context: dict) -> float:
"""
Risk scoring based on tool type, parameters, and context.
"""
base_risk = {
"database_write": 0.8,
"api_call": 0.5,
"file_read": 0.2
}.get(tool_call["type"], 0.3)
# Increase risk if operating on production data
if context.get("environment") == "production":
base_risk *= 1.5
# Increase risk if parameters include sensitive fields
if any(key in tool_call["params"] for key in ["password", "api_key", "ssn"]):
base_risk *= 2.0
return min(base_risk, 1.0)This guardrail sits between the agent’s decision to call a tool and the actual execution. It calculates risk based on tool type, environment, and parameter sensitivity. High-risk calls either block or route to human approval. The key: this is not a post-hoc audit. It is a synchronous gate in the execution path.
Technical Verdict
Use this stack when:
- You need to ship agents into production environments where failures have financial, legal, or safety consequences
- Your team has the instrumentation to capture human feedback and route it back into training pipelines
- You can map tasks to specific autonomy levels based on actual constraints and verification capabilities, not aspirational maturity
Avoid this stack when:
- Your use case is purely experimental or research-focused, where the overhead of guardrails and feedback loops exceeds the value
- You lack the infrastructure to implement synchronous guardrails at tool invocation boundaries (this requires deep integration with your execution layer)
- Your team cannot commit to maintaining eval datasets and retraining loops (static guardrails degrade as agent capabilities and task requirements evolve)
The convergence of these three talks is rare: technical guardrail architecture, human collaboration patterns, and autonomy calibration frameworks are usually discussed in isolation. Together, they expose the full stack required to move agents from demo to deployment. The plumbing is not glamorous, but it is what separates systems that ship from systems that stall in pilot purgatory.