State, Memory, and Data Model

Durable state, scoped memory, replay, and core objects.

State, Memory, and Data Model

AgentWorld needs durable state because businesses are long-lived systems.

Prompt history is not enough. A business runtime needs explicit objects, versioned transitions, and replayable execution records.

Three memory planes

The platform should separate memory into three planes.

1. Ephemeral context

This is short-lived execution context.

It includes the active task, recent artifacts, temporary tool outputs, and model-facing context windows. It is useful during a run. It should not be treated as canonical business truth.

2. Operational memory

This is durable business memory.

It includes customers, vendors, tasks, workflows, policies, approvals, reports, and prior outcomes. It should be queryable, typed, and versioned.

3. Canonical financial state

This is the value-bearing source of truth.

It includes treasury balances, transaction intents, settlement records, and onchain confirmations. In many cases, the final authority for this plane is external to the runtime and must be reconciled into it.

Core object model

A practical AgentWorld deployment should define at least these object types:

• agent

• workflow

• task

• run

• artifact

• tool_call

• approval

• policy

• wallet

• transaction_intent

• settlement_record

Each object should have its own lifecycle and audit trail.

Example run record

{
  "run_id": "run_01",
  "agent": "pricing-agent",
  "task": "quote-review",
  "input_refs": ["lead_87", "pricing_policy_v3"],
  "outputs": ["artifact_quote_19"],
  "tool_calls": ["crm.read", "margin.calc"],
  "status": "completed",
  "started_at": "2026-03-07T12:00:00Z",
  "ended_at": "2026-03-07T12:00:12Z"
}

This record is compact, but it already supports observability, replay, and compliance review.

Scoped memory access

Agents should never read the full world by default.

Memory scope should be derived from role, task type, and policy context. A collections agent may read invoices and customer history. It should not automatically read treasury strategy, unrelated accounts, or policy drafts.

This improves both safety and model quality.

Versioning and replay

Every material state change should be append-friendly.

That does not require event sourcing for everything, but the system should preserve enough history to answer these questions:

• what was known at the time of execution

• which policy version was applied

• which artifacts were used

• which tool outputs were accepted

• why the next state was chosen

Without that, debugging and audit become guesswork.

Artifacts versus state

Agent output should usually start as an artifact.

Artifacts are drafts, analyses, summaries, plans, and generated payloads. They become state only after validation or acceptance. This separation keeps the system from accidentally treating model prose as authoritative business truth.

Tenancy and isolation

If multiple businesses or business units run on the same platform, isolation rules must be explicit.

At minimum, the system should isolate:

• memory scopes

• workflow namespaces

• policy sets

• wallet authority

• observability views

A strong multi-tenant design prevents cross-account leakage and reduces blast radius.

A durable agent system is mostly a state model with a reasoning engine attached to it.