Why AI Agents Need a Simulation Layer

An applied research thesis from financial services.

Most production artificial intelligence (AI) agents use a short loop. A request arrives. The system retrieves context. A model selects a tool. The tool changes a system, and the agent returns a response.

prompt → retrieval → tool call → response

Careful engineering makes this loop useful. However, the loop gives the model a direct path to a real system. That path limits safe use.

We propose a runtime layer between model output and system changes. In this layer, agents observe structured state, retain experience, make plans, and rehearse actions. We call this layer simulation. We treat simulation as a software primitive, similar to a database, message queue, or deterministic state machine.

This article presents a research thesis, not a product claim. The thesis applies to many industries, but we test it in financial services. Financial controls make weak system boundaries easy to see. A compliance constraint can force a cleaner architecture.

A scenario that shows the gap

A relationship manager at a regional bank asks an AI assistant: "Freeze Mr. Patel’s account. We received a fraud alert."

The assistant can make one application programming interface (API) call. Its prompt permits access to the core banking platform. Retrieval found the account. The tool registry contains `freeze_account(account_id, reason)`. The model has processed similar requests.

A direct tool call would create unacceptable risk. Mr. Patel has three joint accounts with his wife. A scheduled 5 p.m. wire will pay his daughter’s tuition. His mortgage application entered final underwriting yesterday. A similar alert on Tuesday resulted from a known travel pattern.

A manager can coach a junior banker who misses this context. The AI agent does not retain judgment in the same way. It has a context window and a tool specification. Those components do not provide an enduring view of the customer or the consequences.

This gap appears when an agent acts for an institution, rather than answering one user. Banking makes the cost immediate and measurable.

Why tools and memory are not sufficient

More tools let an agent perform more actions. They do not show the agent what each action will change. The account scenario does not require another tool. It requires a view of the effects across customers, workflows, and systems.

Memory also helps, but memory alone does not solve the problem. A vector store can find the customer’s travel pattern. It cannot predict that an account freeze will affect tomorrow’s underwriting check. A vector store retrieves facts. It does not run a model of the institution.

The agent needs a runtime that connects state, experience, plans, and possible effects. Park and the other authors demonstrated this pattern with generative agents in a simulated town. We apply the pattern to regulated production systems. In these systems, weak judgment causes audit and customer harm.

What simulation is not

Several established systems resemble this simulation layer. The following distinctions define the proposed boundary.

It is not workflow orchestration. Temporal, Cadence, and Airflow coordinate steps, retries, timeouts, and durable state. A workflow engine runs a step. The simulation layer predicts what will happen if the step runs. It then helps the agent decide whether to propose that step.

It is not a policy engine. Open Policy Agent, Cedar, and custom rules services return an allow or deny result. The simulation layer predicts downstream changes after an allowed action. These changes can include notifications, broken workflows, and missed customer commitments. A production system can use both components.

It is not a digital twin. A digital twin copies the state of a physical system for monitoring and prediction. The simulation layer models institutional state and the agents within it. The two systems share a lineage, but they have different data and users.

It is not a belief-desire-intention agent or classical planner. These systems model one agent or produce a sequence of actions. The simulation layer provides the world model where one or more agents test those actions. It can include these planning systems.

It is not a proposal-and-approval system. Change tickets and four-eyes workflows help people review a proposed change. The simulation layer prepares the proposal and its context. A person, another agent, or the kernel can then accept or reject it.

Generative agents are the closest related system. Park and the other authors showed agents that observed state, retrieved memories, reflected, and planned. We add a deterministic kernel below that pattern. The kernel makes the pattern suitable for controlled production use.

The architectural split

The architecture separates judgment from system changes.

Most regulated systems already contain a deterministic core. Examples include ledgers, rules engines, workflow orchestrators, and audit logs. These systems own state changes. They work because they are narrow, replayable, and verifiable.

People perform much of the work around this core. They manage relationships, exceptions, fraud reviews, compliance interpretation, communication, and coordination. Current AI products often connect a language model directly to the core to automate this work.

We propose two separate layers:

• A deterministic kernel owns validation, system changes, and commitment. It enforces invariants and rejects actions that violate policy. The kernel stays small and auditable.
• A simulation layer owns interpretation, memory, planning, and proposals. It models customers, objects, workflows, risk states, and agent coordination. It cannot commit changes.

A constrained interface connects the layers. The simulation layer observes state and stages proposals. It can ask the kernel to permit a proposal. Only the kernel can commit the proposal.

The kernel provides predictable controls. The simulation layer provides context and judgment. Their interaction produces the product behavior.

A person often provides the simulation function in current operations. The person interprets context, forms a judgment, and submits a request. The core system then makes the controlled state change.

A direct model connection removes this separation. It gives a generative system control of a deterministic function. The result has no reliable boundary between a useful action and a harmful action.

What the simulation layer contains

The layer has five connected components. Each component depends on the others. Memory needs selective retrieval. Retrieval needs reflection. Reflection needs plans. Plans need grounding. Grounding needs memory to preserve context between requests.

A memory stream. Systems of record store current facts. The memory stream also stores attempts, observations, conclusions, and the reasons for decisions. This history gives the agent continuity between requests.

Retrieval with saliency. Semantic similarity alone does not identify the most important memory. Retrieval must also consider regulatory importance, customer effect, workflow timing, and known false-positive patterns. It must return the few memories that can change the decision.

Reflection. Individual events can hide an important pattern. Reflection converts repeated observations into a higher-level conclusion. For example, repeated Monday approval delays can show that a team lacks capacity. The system can retrieve and test that conclusion later.

Hierarchical planning. An agent needs a broad goal, a daily plan, and an immediate next step. It must update the plan when conditions change. Without this hierarchy, actions can look reasonable separately but conflict across a workflow.

Semantic grounding. Production systems use structured objects, such as accounts, alerts, holds, claims, and policies. A grounding layer connects model text to these objects. It identifies permitted actions, staged proposals, and prohibited actions.

Each component has prior research or operating precedent. Our claim concerns their combination. Together, they form a runtime for AI systems in regulated domains.

Capabilities that the layer can provide

The architecture must provide capabilities that a prompt and tool stack cannot provide alone. We will test the following capabilities.

Safe previews before an action. The agent simulates a proposal before commitment. The preview identifies notifications, workflow failures, customer effects, and downstream locks. The kernel state does not change during this test. The result can support a decision to permit or reject the action.

Persistent role behavior. A system prompt can assign a role name, but it does not create role experience. A simulation layer can retain past cases, recurring exceptions, work routines, and escalation relationships. This history makes role behavior consistent across requests.

Multi-agent coordination. Institutional workflows include multiple roles. A shared world model gives each agent the same state and defined responsibilities. It also structures handoffs, conflicts, and escalations. Direct message passing does not provide this shared operating context.

Counterfactual analysis for an institution. A team can test an alert threshold, policy change, or staffing change before production. The simulation predicts effects on customers, queues, and service-level agreements. Teams can compare options without changing the live system.

Structured explanations. A proposal can identify its observations, retrieved memories, conclusions, plan, and applicable policy. This record differs from a model-generated explanation after a decision. Regulators have not defined one explanation standard for AI-assisted actions. A structured audit trail gives them evidence they can inspect.

Why we test this in financial services

A bank cannot accept the weak boundaries that a consumer chatbot might accept. An incorrect account freeze can harm a customer and violate controls. It can also cause an audit finding or regulatory event.

This low tolerance forces a clear separation between proposals and commitments. It also requires explicit status and a structured audit trail.

The architecture also applies to other regulated operations with deterministic cores and high costs for incorrect actions:

• Lending. The core contains the credit decision and loan ledger. The simulation layer handles borrower context, exceptions, documents, covenants, and restructuring discussions.
• Payments. The core contains settlement. The simulation layer handles exceptions, disputes, chargebacks, merchant relationships, and risk patterns.
• Insurance. The core contains the policy contract and claim decision. The simulation layer handles intake, expert interpretation, fraud review, customer communication, and escalation.
• Capital markets operations. The core contains settlement and reconciliation. The simulation layer models counterparties, breaks, and the operating knowledge used to resolve them.
• Regulatory and supervisory work. The core contains the rule and submitted report. The simulation layer handles interpretation, case history, and communication with the supervised entity.

Open research questions

The architecture still has unresolved questions. Each question below includes a failure condition and an initial test. These tests let evidence change or reject the design.

How can the system limit long-term memory? A year of operations creates a large memory stream. The system must decide which memories to keep, compress, or remove. Saliency-weighted retention is a starting method, not a complete answer.

Failure condition. No compression method preserves the memories that supported past correct decisions. Initial test. Compress old memories during an offline replay. Then compare decisions with an uncompressed baseline across representative workflows.

How should the kernel interface work? The simulation layer must not bypass the kernel. The kernel must not depend on simulation for correctness. The interface must support detailed proposals without permitting hidden system changes.

Failure condition. An adversarial input causes a system change that the kernel did not independently validate. Initial test. Test the proposal interface with prompt injection and malicious tool output. Treat every unauthorized change as a kernel defect.

When should the system create a reflection? Reflection after each event creates noise. Daily reflection can lose detail. Workflow-based reflection has uneven timing. A tiered process might work, but its triggers need tests.

Failure condition. Tiered reflections do not improve retrieval over raw memories. Initial test. Compare retrieval precision and recall for each reflection tier with a raw-memory baseline.

How can simulated effects match real effects? A safe preview must produce calibrated predictions. The system must compare predicted effects with actual results. It must then update the simulation without changing the kernel’s audit record.

Failure condition. Prediction error exceeds the permitted rate on representative workflows. Initial test. Run the simulation beside a live workflow for a defined period. Measure error for each effect type.

How can multiple agents keep one coherent state? Agents can develop conflicting views of the same workflow. The system must maintain shared state and show disagreements. It must not hide a conflict during coordination.

Failure condition. Shared simulation produces more divergent results than direct message passing. Initial test. Run both designs on a fraud workflow with known results. Compare outcome variance and conflict resolution.

These problems appear when an institutional workload runs for more than a few days. Test results will determine which components stay in the architecture.

What we are building

StablecoinRoadmap is our main test of this thesis. The platform supports institutions that issue and operate payment stablecoins. Its deterministic kernel owns minting, burning, reserve attestation, on-chain settlement, and the append-only audit ledger. Its simulation layer owns interpretation, planning, and proposals.

Our compliance scenario generator is one part of that layer. It rehearses corridor openings, reserve changes, and issuance pauses against a current platform model. The simulation predicts the changes. The kernel decides whether to permit them.

We will test four predictions. Safe previews should expand the actions an issuer permits. Persistent role behavior should outperform role prompts. Shared simulation should improve agent coordination. Structured audit trails should support regulatory review better than model-generated explanations.

We also want to test this architecture in lending, payments, insurance, and capital markets. The work uses real operating problems. It remains research because the evidence can still reject the design.

A broader thesis about AI agents

Many AI applications invest in tool connections without building a model of their operating environment. Tools, memory, and workflow orchestration each provide value. None provides enough context alone.

We expect strong AI products to maintain a structured model of the systems where they operate. Their agents will act as controlled participants in those systems. They will not function only as text generators connected to APIs.

This structure could support longer plans, better judgment, and clear explanations. These qualities can help an institution decide which actions an agent can perform.

The test

Our thesis is simple. A simulation layer can turn a reactive assistant into a controlled operating agent. Regulated finance provides a useful test because errors have clear costs.

We are building systems with persistent environments, explicit memory, reflection, and planning. A deterministic kernel governs every real system change. We treat the unresolved questions as engineering tests.

If the architecture works, institutions should permit agents to perform more useful actions with stronger controls. If it fails, the tests should show where and why.