The Guardian at the Gate: Policy Evaluation, Intercepts, and Human-in-the-Loop Orchestration

Giving an AI agent access to tools is powerful, but it also creates a new class of enterprise risk. An agent that can read documents is useful. An agent that can call APIs, update systems, or trigger workflows can create real business value.

But once an agent can act, mistakes become more serious. A wrong answer is one problem. A wrong action is another.

A similar situation came up recently in a workplace context. The exact details were different, but the failure mode was the same. An automated process was trying to “fix” or “clean up” a system condition, and its action path created a risk that was much larger than the original issue.

That is the real concern with agentic systems. If an agent is asked to “fix database performance issues,” the model may decide to call something like drop_table("users") because it reasons that empty tables are faster to search. The example is deliberately extreme, but the architectural point is practical.

That is no longer just a hallucination. That is an operational incident.

This is the key shift in agentic AI. Traditional AI systems were generally more risk-averse because they mostly produced outputs for humans or downstream systems to review. Agentic AI is different because it can reason, select tools, and execute actions.

So the answer is not to avoid agentic AI. The answer is to control it through an enterprise architecture framework. The model can propose actions, but the execution environment must enforce boundaries, approvals, audit, and recovery.

Before we jump into the implementation, it is useful to step back and look at the enterprise architecture problem.

Agentic AI is not only a model capability shift. It is an execution boundary shift. Traditional AI systems were usually advisory. They predicted, classified, summarized, recommended, or generated content.

Even when the output was wrong, the damage was often limited because a human or downstream process still had a chance to review it. Agentic AI changes that assumption.

An agent can reason, select a tool, call an API, update a record, trigger a workflow, or change the state of a system. Once that happens, the risk is no longer only about response quality. It becomes operational risk.

This is why enterprise AI cannot be governed only through prompts. A prompt can describe expected behaviour, but it cannot be the final control boundary. In an enterprise environment, control must sit in the architecture.

This is the same argument we discussed earlier in the context of bounded agentic AI. Autonomy without boundaries is not suitable for enterprise adoption. Agents need defined execution limits, approval gates, audit trails, recovery paths, and clear accountability.

In other words, agentic AI needs a control plane.

But the control plane should not remain only at the level of strategy, principles, or diagrams. It has to appear in the runtime. It has to sit between model reasoning and system execution.

The model can propose an action. The runtime must decide whether that action is allowed, rejected, or paused for human approval.

That is the bridge from enterprise AI architecture to implementation.

In this article, we’ll examine how SolidState structures tool safety using the Interceptor Pattern, Chain of Responsibility Pattern, and Stateful Asynchronous Interrupts to build human-in-the-loop mechanics.

These are not random implementation details. They are runtime expressions of the same enterprise control-plane idea.

The Interceptor Pattern is commonly used in middleware and distributed systems to add services around execution without changing the core component directly. In SolidState, the same idea is applied to tool calls. Before a tool call reaches the executor, it is intercepted by the policy layer.

The Chain of Responsibility Pattern comes from classic object-oriented design. It allows a request to pass through a sequence of handlers, where each handler can either process the request or pass it onward. In SolidState, this maps naturally to modular security and governance rules.

Stateful Asynchronous Interrupts are closer to enterprise workflow and orchestration patterns. When execution needs human approval, the runtime should not block a thread. It should persist state, pause execution, release resources, and resume later through a controlled handshake.

Together, these patterns turn agent safety into an architectural control plane. They move governance away from prompt wording and into runtime enforcement.

Pattern 1: The Interceptor Pattern

In web development, middleware inspects, modifies, or rejects HTTP requests before they reach the route handler. Agent runtimes can use the same idea for tool calls.

Before the runtime executes any ToolCall, it passes the call through a PolicyEvaluator.

The important point is simple. The model does not directly execute tools. It proposes tool calls. The runtime intercepts them, and the policy layer decides what happens next.

A policy decision can produce three outcomes:

allow means the tool call is safe enough to execute immediately. Reject means the tool call violates a hard boundary. The runtime cancels the action, records the refusal, and stops or raises an exception.

An interrupt means the tool call may be valid, but it carries risk. The agent pauses, the state is saved, and a human must approve before execution continues.

This gives the runtime a clear safety model. Not every risky action has to be blocked. Not every action needs manual review. Not every rule belongs in the prompt.

The runtime can apply a policy based on risk.

This is a small piece of code, but architecturally it does something important. It separates intention from execution.

The LLM may intend to call a tool. The runtime decides whether that tool call can proceed. That is the boundary enterprise AI systems need.

Pattern 2: Integrating Interceptors into the Runtime Loop

The interceptor only works if the runtime loop treats policy evaluation as mandatory. Policy evaluation happens after the model outputs tool calls and before those calls are sent to the ToolExecutor.

This control loop captures a major production principle. The runtime must behave like a gatekeeper, not like a blind executor.

If a tool call is rejected, the rejection is written back into the agent state. That matters because the model receives a structured signal explaining why the action failed.

If a tool call requires approval, the runtime does not block the process. It marks the state as paused, stores the pending approval, checkpoints the state, and returns.

That last step is critical.

Why Stateful Interrupts Matter

A common anti-pattern in early agent code is this:

That may work in a demo. It does not work in production.

In a SaaS backend, Slack bot, workflow engine, or distributed application, blocking a thread while waiting for a human is dangerous. The human may respond in five seconds, five hours, or never.

The client connection may disconnect. The server may restart. The process may be rescheduled.

A production AI runtime cannot depend on an in-memory blocking loop. Human approval must be treated as an asynchronous workflow.

When a tool call requires approval, the runtime saves the current state with a status of paused. Then it returns immediately. The agent effectively dies in memory, but its execution context is preserved in durable storage.

This is similar to enterprise workflow systems. A loan approval does not keep a server thread alive while waiting for a manager. A procurement workflow does not block the application until finance responds.

The workflow persists state, waits externally, and resumes when a decision arrives. Agent runtimes need the same pattern.

This is not only a safety feature. It is an enterprise architecture feature.

Pattern 3: The Resume Handshake

Once an agent is paused, it needs a secure way to wake up. That is the resume handshake.

A human may review the pending tool call through a Slack button, web portal, admin console, or API. Once the decision is submitted, the runtime resumes the agent from its checkpointed state.

This handshake does three important things. First, it reconstructs the agent state from persistent storage. Second, it records the approval decision for auditability. Third, it either rejects the action or executes the approved tool calls.

After that, the agent continues its run.

This creates a clean separation between model reasoning, policy evaluation, human approval, tool execution, state persistence, and audit tracing.

That separation matters in enterprise AI. Once agents interact with real systems, every action needs to be explainable.

Who approved it? What was approved? What parameters were used? What did the tool return? What state did the agent continue from?

These are not minor implementation details. They are governance requirements.

Designing Governance with the Chain of Responsibility

The first version of a policy evaluator may start with simple checks. Block critical tools, require approval for high-risk tools, and interrupt large transactions.

But enterprise policy rarely stays simple.

Different teams may need different rules. Different tools may carry different risks. Different environments may have different thresholds. Different users may have different approval limits.

Hardcoding all of that into one large PolicyEvaluator becomes messy. This is where the Chain of Responsibility Pattern helps.

Instead of one monolithic evaluator, the runtime can maintain a list of security rules. Each rule checks the tool call. It either returns a decision or passes control to the next rule.

The evaluator chains through these rules. The first rule is to return a winning decision. This keeps policy modular.

A security team can own blacklist rules. A finance team can own budget rules. A data governance team can own sensitive data rules. A platform team can own runtime-level safety rules.

This is the enterprise architecture parallel. A good AI runtime should not bury governance inside prompts. It should not scatter safety logic across tool code.

It should expose governance as a composable policy layer.

This distinction matters because many current agent frameworks focus heavily on model orchestration, tool registration, memory, and workflow composition. Those are important, but they do not automatically solve runtime governance.

A framework may allow tools to be registered, but that does not mean every tool call is policy-mediated. A framework may support callbacks or middleware, but that does not mean it has a clear enterprise approval model.

A framework may log events, but logging after execution is not the same as preventing unsafe execution.

SolidState addresses this gap directly. Tool calls are not treated as simple function calls. They are treated as governed execution requests.

That is why the policy evaluator sits between the model and the tool executor. That is why high-risk actions can be interrupted. That is why the state is checkpointed before waiting for human approval.

That is also why the resume handshake is explicit rather than hidden inside an ad hoc callback.

This is not just implementation hygiene. It is the difference between an agent that can call tools and an agent runtime that can operate safely inside an enterprise.

Safety Is a First-Class Architecture Concern

Safety is not an afterthought. It is not solved by adding “please do not delete tables” to the system prompt. It must be designed into the runtime.

Placing interceptors before tool execution makes the runtime safer. By validating tool parameters, it becomes more controlled. Converting blocking approvals into stateful interrupts makes it production-ready.

By using a secure resume handshake, the agent becomes auditable and resilient. It can still reason, act, and complete useful workflows, but it acts within controlled boundaries.

That is the real foundation for enterprise-grade agentic AI. Not just better prompts. Not just better models. A better execution architecture.

In the next article, “Time Travel & Memory: Persistence Engines, State Checkpointing, and Event Sourcing,” we will look at how agents survive server crashes, client disconnects, and long-running workflows by saving, loading, and auditing state across distributed backends such as Redis and AWS DynamoDB.

References

1. Schmidt, D., Stal, M., Rohnert, H., & Buschmann, F. Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. Used here for the Interceptor Pattern lineage.

2. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Used here for the Chain of Responsibility Pattern lineage.

3. Durable workflow and human-in-the-loop orchestration practices. Used here to relate stateful pause, durable execution, and resume workflows to production AI agent runtimes.