Kam State documentation
Reduce custom state-management work around your AgentCore application with exact State and History.
// Save as a .mjs file in an authorized backend source checkout. SDK candidate 0.40.0.
// This is a read-only example, not code executed by the website.
import { createKamClient } from './server/trajectory/sdk/index.mjs';
const kam = createKamClient({
baseUrl: process.env.KAM_API_URL,
tenantId: process.env.KAM_TENANT_ID,
accessToken: () => process.env.KAM_ACCESS_TOKEN,
});
const deployments = kam.scope({ subjectId: 'checkout', type: 'deployment' });
const page = await deployments.allIds({ day: '2026-10-06', limit: 16 });
if (page.status === 'ready' && page.items.length > 0) {
const exact = await deployments.byIds({
day: page.day,
generation: page.generation,
refs: page.items,
});
console.log(exact.records); // Keep every position and result status.
}
// A short page is not the end when nextCursor is present.
// Continue with the SAME generation and returned cursor.How to choose a starting task
Reduce custom state-management work around your AgentCore application with exact State and History. Start with one result your application can record and one exact version the next task needs. The existing examples show the evidence; they do not run AgentCore.
Ask your coding agent
Explain how Kam State fits my Amazon Bedrock AgentCore application. Read https://kam-ai.com/llms.txt, separate State and exact History from runtime execution and Memory recall, and identify what is implemented, locally tested or still planned before suggesting integration steps.
What’s new
- Exact Context and history inspection in private SDK 0.40Implemented in source
- State queries, Components, and the native toolkit land on mainImplemented in source
- Turn-cycle preparation joins the Rust developer toolkitMerged · local only
Engineering review
Review the State layer beside AgentCore: storage, exact reads, recovery and qualification.
Integrate a workload
Record one AgentCore workload result, retry its identity, correct it and read both versions.
State queries
Select bounded evidence for a task; inspect the plan before your application reads it.
History contract
Preserve recorded versions and fixed lists without replaying agent or tool execution.
Glossary
Separate State, History and recall from runtime execution and application decisions.
History console
Inspect authorized State History read-only; live access requires separate qualification.
Core concepts
- State
- The recorded results and exact versions your agents read and share.
- Revision
- One version of a record. A correction adds the next revision; earlier ones stay readable while retained.
- View
- A saved question over State, such as at-risk customers. A materialized View stores its answer and reports whether the result is current, stale, blocked, or absent.
- Generation
- A fixed, published snapshot of which exact revisions belong to a collection.
- Checkpoint
- Saved processing progress used to resume work. It is not a permanent summary.
Guide context
Use Kam State alongside Amazon Bedrock AgentCore. Start with one recorded result, read its exact version, and learn which source capabilities and integration steps still need qualification.
Kam State is a State Management add-on for Amazon Bedrock AgentCore. Your application records results and selects exact retained evidence; AgentCore hosts agents and tools. Systems of record remain authoritative for their own business data, and Memory recall stays separate.
On this page · 4 sections
What Kam does today#
Your app sends results to Kam. Kam keeps numbered versions and corrections, returns the exact retained version requested, and reports when it cannot. Kam uses declared dependencies to identify and reconcile affected Views. General metric APIs, materialize and watch remain planned.
Amazon Bedrock AgentCore hosts your agents and tools. Your application decides when to call them and what their results mean. Kam preserves the State and exact versions your application records; AgentCore Memory provides separate recall.
Identity · Implemented in source
Stable logical identity for every entity, so a correction updates the same thing instead of creating a duplicate.
Versions · Implemented in source
Immutable revisions. A newer revision never rewrites what an older read returned.
Membership · Implemented in source
A fixed, ordered list of the exact revisions that belong to one collection at one point in time.
History · Implemented in source
The retained record of accepted revisions, corrections, and published generations.
Dependencies · Implemented in source
Versioned records of which Views read which sources, so a change can find exactly what it affects.
Views · Implemented in source
Bounded, owner-configured definitions over source State, normalized and hash-bound by Rust.
Materialization · Implemented in source
Conditionally committed Active State for bounded same-scope Views with one or more sources. Source implementation, not a public hosted service.
Queries · Implemented in source
Bounded where, pick, orderBy and take over one Active State's evidence, with explain() before value().
Replay · Implemented in source
Re-run synthetic scenarios against the real Rust engine and explain why State changed or was reused.
Metrics · Planned · not available
General derived metrics that recompute when an input changes. Today only rolling outcome comparisons are implemented.
Watch · Planned · not available
Customer subscriptions that fire when a materialized view changes.
Three questions Kam answers today#
What exact evidence existed?
History preserves accepted revisions and fixed membership under stable identity.
What changed, and which Views need reconciliation?
Versioned Views and State reconciliation separate affected dependencies from retained immutable evidence.
What should this reasoning turn see?
Your app selects exact captured evidence in a versioned Context manifest. Bounded assembly exists in source; the native toolkit also prepares local reference-only Turn Frames. Managed runtime wiring remains planned.
Choose the right entry point#
Start with private SDK 0.40.0. Exact History, Views, current-State reads, bounded queries and versioned Context manifests are implemented in source. The reviewed package receipts qualify local or simulated execution; they do not establish a publicly offered hosted service, live production use or a Marketplace listing.
A rolling view, not permanent recall#
The working history covers 365 UTC dates. Supporting evidence has its own inspection limits. A recovery checkpoint is saved processing state, not a lifetime summary.