Architecture

See where Kam can reduce custom state infrastructure.

Kam is designed to reduce custom infrastructure for exact State, declared dependencies, and recovery of accepted processing. Your Amazon Bedrock AgentCore application runs agents; Kam records versions and input references. Review the contracts and remaining live checks.

On this page

Data flow

Where data moves, and where access is checked.

Implemented in source; not a live deployment. The console uses only read routes.

Choose a path

What happens when a result changes?

AgentCore application
Submit a recorded outcome with stable identity.
Kam admission
Check scope, revision, and bounded input.
Accepted event
Commit the recorded outcome under version conditions.
Publication
Keep a durable record of downstream work still owed.

Conceptual examples of contracts implemented in source. They are not live traces. Optional AgentCore Memory delivery is implemented, off by default, and not live-qualified. Inspect the corresponding example →

Inspect five paths through a release

One workflow, five paths

Inspect retries, corrections, and restarts.

These synthetic paths show what gets recorded and which checks can reject a write. They do not prove a release is safe.

A release report across three agents. One agent records a build, another tests that exact version, and a third reads the saved readiness result.

01
Normal path
Each agent reads the exact State the previous one wrote.
Normal path trajectory. Each agent reads the exact State the previous one wrote. Readiness is current and points to build@1 and tests@1.
- build@1 recorded: Agent A
- tests@1 recorded: Agent B · against build@1
- readiness reconciled: View reads both revisions
- readiness: current: Agent C · byIds + read()
- build@1 recorded → tests@1 recorded
- tests@1 recorded → readiness reconciled
- readiness reconciled → readiness: current
Outcome: Readiness is current and points to build@1 and tests@1.
02
Retry
Agent A resends the same build after a timeout.
Retry trajectory. Agent A resends the same build after a timeout. The same submission returns the original receipt. It adds no revision or repeated calculation in this example.
- build@1 recorded: Agent A
- same payload resent: status: duplicate
- original receipt: same acceptedSequence
- readiness unchanged: nothing to reconcile
- build@1 recorded → same payload resent
- same payload resent → original receipt
- original receipt → readiness unchanged
Outcome: The same submission returns the original receipt. It adds no revision or repeated calculation in this example.
03
Correction
The build result is corrected after tests already ran.
Correction trajectory. The build result is corrected after tests already ran. build@1 stays readable while retained; readiness is not current until tests target build@2.
- build@2 recorded: correction · build@1 kept
- readiness re-evaluated: View requires tests for the current build
- readiness: blocked: tests@1 point to build@1
- tests@2 recorded: Agent B · against build@2
- readiness: current: points to build@2, tests@2
- build@2 recorded → readiness re-evaluated
- readiness re-evaluated → readiness: blocked
- readiness: blocked → tests@2 recorded
- tests@2 recorded → readiness: current
Outcome: build@1 stays readable while retained; readiness is not current until tests target build@2.
04
Stale worker
A delayed worker tries to commit readiness from old inputs.
Stale worker trajectory. A delayed worker tries to commit readiness from old inputs. The required-version check rejects the old write and keeps the newer State.
- delayed worker: computed from build@1
- conditional commit: expected version moved
- commit rejected: no overwrite
- newer State kept: build@2 readiness stands
- delayed worker → conditional commit
- conditional commit → commit rejected
- commit rejected → newer State kept
Outcome: The required-version check rejects the old write and keeps the newer State.
05
Restart
The wakeup is lost while a worker restarts.
Restart trajectory. The wakeup is lost while a worker restarts. A saved work record lets the maintenance pass retry unfinished work in this example.
- tests@1 accepted: work record committed
- wakeup lost: worker restarted
- maintenance sweep: durable work redriven
- readiness: current: delayed, not lost
- tests@1 accepted → wakeup lost
- wakeup lost → maintenance sweep
- maintenance sweep → readiness: current
Outcome: A saved work record lets the maintenance pass retry unfinished work in this example.

An example. Each step shown is built in code; the scenario has not run on a live deployment.

One system, clear responsibilities

Give each system a clear job.

Responsibility	Owner
Agent execution and tool orchestration	Your agents and application on AgentCore
Business data and source-of-truth updates	Your existing databases and services
Accepted History and exact revisions	Kam
Supported derived State and dependency reconciliation	Kam
Conversational recall and semantic retrieval	AgentCore Memory or a retrieval system
General-purpose analytics	Your warehouse or analytics platform

Database and distributed-systems contracts

For engineers

Database and distributed-systems contracts.

Exact identity: Retained revisions stay individually addressable. A correction does not replace the revision an earlier decision used.
Versioned membership: Bounded collections are pinned to a generation, so pagination does not shift when newer records arrive.
Deterministic State evaluation: The Rust engine evaluates supplied evidence against versioned definitions. Proposed transitions stay separate from committed ones.
Conditional publication: Expected versions, dependency membership, and authority checks stop a stale writer from overwriting a valid successor.
Event-driven reconciliation: Accepted changes identify declared dependent Views that may need updates. Kam saves reconciliation progress and processes those Views in bounded steps guarded by version checks.
Explicit recovery: Retries, conflicts, missing evidence, and unknown outcomes mean different things. A recorded submission is not a verified completion.

Choose a tool by responsibility

Which tool for which job

Choose each tool for the responsibility it owns.

Job	Kam	Your database	AgentCore Memory	Vector database	Warehouse
Read the exact version a decision usedKam: byIds resolves (id, revision) and reports missing or expired explicitly.	Built for this	Varies by system	Outside its role	Outside its role	Varies by system
Keep one fixed list across agent turnsKam: allIds pages one generation; a late write publishes a successor instead of shifting the page.	Built for this	Varies by system	Outside its role	Outside its role	Varies by system
Update the related State a change affectsKam: Views reconcile same-scope dependents; metrics and watch are planned.	Built for this	Varies by system	Outside its role	Outside its role	Varies by system
Keep business transactions and source-of-truth writesYour database stays authoritative for its records.	Outside its role	Built for this	Outside its role	Outside its role	Outside its role
Recall what was said in past conversationsAgentCore Memory owns recall; Kam can optionally publish to it.	Outside its role	Outside its role	Built for this	Varies by system	Outside its role
Find similar documents or passagesSimilarity search belongs in a vector store beside Kam.	Outside its role	Varies by system	Varies by system	Built for this	Outside its role
Run custom analytics across all your dataKam does not offer general SQL or arbitrary joins.	Outside its role	Varies by system	Outside its role	Outside its role	Built for this

Kam’s column describes reviewed source contracts. Private packages and offline tests do not establish live qualification. Other columns are general categories, not products or benchmarks.

Which questions can the State model answer?

One State model, many questions

Exact records and declared dependencies support these State questions.

Each question on the right is answered by the blocks wired to it. Some belong to AgentCore or a model, and say so.

One State model, many questions. Eight primitives on the left; each concept on the right is answered by the primitives connected to it, or belongs to the runtime or a model.

Identity: stable id per scope
Revision: immutable (id, revision)
Membership: generation-pinned sets
View + dependencies: versioned, reverse-indexed
Authority: principal → workspace
Bounds: limits checked before work
Obligation + receipt: owed work, acknowledged result
Retention clock: evidence deadlines
Agent on AgentCore: plans, decides, calls tools
A model: predicts, scores
Calendar periods: Derivable from existing primitives
Recommended reviews: Derivable from existing primitives
Calendar summaries and patch notes: Derivable from existing primitives
Personal watchlist: Planned
Since my last review: Derivable from existing primitives
Saved calculation selection: Planned
Operational memory: Planned
Workflow coordination: Planned
Computation reuse: Planned
History: Implemented in source
Correction: Implemented in source
Snapshot: Implemented in source
Difference: Derivable from existing primitives
Dependency: Implemented in source
Invalidation: Implemented in source
Freshness: Implemented in source
Authority: Implemented in source
Expiration: Implemented in source
Receipt: Implemented in source
Bounded query: Implemented in source
Context budget: Implemented in source
Subscription: Planned
Authorized history: Needs data Kam does not record
Decision: AgentCore or your runtime
Confidence: A model, not Kam

Identity → Calendar periods
Revision → Calendar periods
Membership → Calendar periods
View + dependencies → Calendar periods
Bounds → Calendar periods
Identity → Recommended reviews
Revision → Recommended reviews
Membership → Recommended reviews
View + dependencies → Recommended reviews
Bounds → Recommended reviews
Identity → Calendar summaries and patch notes
Revision → Calendar summaries and patch notes
Membership → Calendar summaries and patch notes
View + dependencies → Calendar summaries and patch notes
Bounds → Calendar summaries and patch notes
Identity → Personal watchlist
Membership → Personal watchlist
Authority → Personal watchlist
Bounds → Personal watchlist
Revision → Since my last review
Membership → Since my last review
View + dependencies → Since my last review
Bounds → Since my last review
Identity → Saved calculation selection
Revision → Saved calculation selection
Membership → Saved calculation selection
View + dependencies → Saved calculation selection
Identity → Operational memory
Revision → Operational memory
Obligation + receipt → Operational memory
Membership → Workflow coordination
View + dependencies → Workflow coordination
Authority → Workflow coordination
Obligation + receipt → Workflow coordination
Revision → Computation reuse
View + dependencies → Computation reuse
Bounds → Computation reuse
Authority → Computation reuse
Identity → History
Revision → History
Revision → Correction
Membership → Snapshot
Revision → Snapshot
Membership → Difference
Revision → Difference
View + dependencies → Dependency
View + dependencies → Invalidation
Revision → Invalidation
View + dependencies → Freshness
Retention clock → Freshness
Authority → Authority
Retention clock → Expiration
Revision → Expiration
Obligation + receipt → Receipt
View + dependencies → Bounded query
Bounds → Bounded query
Identity → Context budget
Revision → Context budget
Membership → Context budget
Authority → Context budget
Bounds → Context budget
View + dependencies → Subscription
Obligation + receipt → Subscription
Authority → Authorized history
Membership → Authorized history
Agent on AgentCore → Decision
A model → Confidence

See all 25 questions and how each is answered

Concept	Question	Status	How
Calendar periods	What exact History belongs to this year, month, week, day, or saved date range?	Derivable from existing primitives	The frontend calendar builds normalized yearById, monthById, weekById, dayById, and customById selectors over supplied exact History. Ordered year, month and day children share one occurrence catalogue; structural dates have unknown source coverage. One displayed year can include 366 calendar dates without widening the 365-date read or custom-range limits. Browser presets save date preferences only; cross-page collection, scheduling, and Google Calendar synchronization are not implemented.
Recommended reviews	Which supplied changes and recorded readers match a declared review rule?	Derivable from existing primitives	A frontend review policy groups exact input-version differences, reported failed checks and unavailable lookups into bounded, inspectable review roots. Candidates preserve source coordinates, recorded paths, coverage and work limits. Calendar containment is separate from dependency reads. The authorized console does not supply exact dependency edges today; it cannot infer them from opaque source references. Recommendations do not certify importance, confidence, safety, or action eligibility, and do not execute work.
Calendar summaries and patch notes	What changed in this period, and which exact versions have recorded readers?	Derivable from existing primitives	A bounded frontend selector summarizes supplied occurrences, compares successive exact revisions of the same State identity, and searches recorded labels, values and reader references. A prior supplied revision may sit outside the chosen dates; its boundary remains visible. Patch notes show supplied before/after evidence and name recorded readers without implying that a newer revision was consumed. Summaries use deterministic counts and templates, not model inference. Missing pages, prior revisions and dependency evidence remain unknown.
Personal watchlist	What records do I want to follow, in my order?	Planned	An ordered reference collection with per-entry selectors. The public explorer has a temporary fixture preview; authorized, durable watchlist mutations are not implemented.
Since my last review	What changed, and why does my declared review rule flag it?	Derivable from existing primitives	The release-verification fixture View separates endpoint differences, retained activity, and a named domain rule. Explicit review actions acknowledge displayed exact boundaries in memory only; durable reviews and notifications are not implemented.
Saved calculation selection	Which supported calculation, inputs and period produced this result?	Planned	A definition selects a qualified domain calculator and pinned inputs; its result is versioned State displayed by Views. No new backend primitive or generic business calculator is claimed.
Operational memory	What work can a replacement agent recover?	Planned	History and obligations are retained; an explicitly opened local SQLite host can recover accepted records and pending projection work. Managed recovery of whole agent tasks remains planned; the explorer runs no agent.
Workflow coordination	Which parent-child work is eligible?	Planned	Ordered membership and explicit dependencies are separate. The explorer previews valid order; hosted customer workflow management is planned.
Computation reuse	What can be reused without mistaking stale input for a cache hit?	Planned	Local comparison reuse and bounded reads exist. General calculation caching needs explicit applicability and live measurement; fixture counts are not savings.
History	What exactly was recorded?	Implemented in source	allIds() names exact revision references; byIds() returns exactly those revisions.
Correction	What was revised, and what did it replace?	Implemented in source	A correction is the next revision; the earlier one stays readable while retained.
Snapshot	What did this collection look like when it was published?	Implemented in source	A generation fixes ordered membership; pages are read against it.
Difference	What changed between two publications?	Derivable from existing primitives	Compare exact membership from two generations. The SDK also has bounded diffRevisions over two declared selected-reference arrays; it does not establish a generic generation-diff endpoint or external source completeness.
Dependency	What relies on this information?	Implemented in source	Views register versioned dependencies; a reverse index finds dependents.
Invalidation	Which derived State must be recomputed after this change?	Implemented in source	Reconciliation pages through affected Views and recomputes only those.
Freshness	Is this current enough to act on?	Implemented in source	Active State reports current, stale, blocked or absent. Only current carries usable items; the application still decides whether to act.
Authority	Who may read this, in which scope?	Implemented in source	The service resolves the principal's workspaces; a tenant in a request is not permission.
Expiration	When does this evidence stop being usable?	Implemented in source	Reads report expired at the deadline, before storage cleanup.
Receipt	What work is still owed, and what was acknowledged?	Implemented in source	Delivery keeps one obligation per eligible generation and separate receipts.
Bounded query	Which current evidence matches, within declared work limits?	Implemented in source	explain() reports the query plan and fixed work limits; value() executes the query over one Active State’s evidence references.
Context budget	Which selected exact evidence fits this context budget?	Implemented in source	An ordered, versioned Context manifest selects exact captured evidence and full, descriptor or excluded representations. Assembly enforces item and byte limits; unavailable required evidence blocks a complete package. Automatic relevance ranking and provider-token budgeting remain planned.
Subscription	Which agents should wake when this changes?	Planned	watch() is planned; the internal event path is not a customer subscription.
Authorized history	What was this agent allowed to see yesterday?	Needs data Kam does not record	Access is checked at read time and is not itself recorded as History.
Decision	What should the agent do next?	AgentCore or your runtime	Your agents and application on AgentCore plan, decide, and call tools. Kam records the outcome and the exact State the application reported as input.
Confidence	How likely is this forecast to be right?	A model, not Kam	A model computes it; Kam can retain the output and its inputs as evidence.

Status describes code, not a deployment. Derivable: the parts exist, but no built-in operation yet.

Delivery obligations and receipts

Delivery · built, off by default

See which deliveries finished and which stopped.

A delivery record keeps unfinished work visible. A sent receipt and a verified match are different results.

Delivery state graph

Each arrow is a step the backend can take. Sent and verified are separate receipts.

Every step and stop state

AWAITING_PUBLICATIONWaiting to publish
An eligible generation has a durable delivery record. The publisher uses its authorized destination and stable request identity.
AWAITING_VERIFICATIONWrite acknowledged
Submission is confirmed. An exact retrieval check is still required; this is not a claim that an agent has read it.
VERIFIEDExact record matched
The read matched content, destination, metadata, and local-generation lineage at the verification time.

An uncertain response keeps the same stage and request identity and retries after a bounded delay. Retries are bounded, not unlimited.

REJECTED
The publication was rejected. It remains visible in delivery status.
AUTHORITY_BLOCKED
Lifecycle authority closed or the destination binding changed. Old work is not silently rebound.
RECONCILIATION_REQUIRED
A mismatch or exhausted attempt budget needs review. The worker does not repair remote content.
SUPERSEDED
Policy v2 only: a newer generation replaced a candidate that was never planned, dispatched or submitted. The replaced obligation is kept with the replacing generation. Submitted or uncertain work is never coalesced.

From the backend’s delivery code at the reviewed commit. Stop states are not success. VERIFIED proves an exact match at one time, not that an agent used it correctly.

Explore another State question

Inspect an example

The same State, from another angle.

Go deeper

Read the contracts behind the diagrams.

One application. One workflow.

Evaluate Kam State for your AgentCore application.

Bring one workflow with a correction or retry. Agree the baseline, scope, and success checks before starting.

Plan an evaluation Read the evaluation scope

Where data moves, and where access is checked.

What happens when a result changes?

Inspect retries, corrections, and restarts.

Normal path

Retry

Correction

Stale worker

Restart