Skip to main content

Solutions · for technical buyers

Reduce the state infrastructure your team has to build.

Kam State is designed to reduce custom work around versioned records, scoped reads, retries, and corrections in an Amazon Bedrock AgentCore application. Review the implemented contracts and measure the value for your workflow.

One product, five technical questions

Find the evidence for your architecture decision.

Principal engineer

Which correctness mechanisms does Kam own, and which remain mine?

Exact revisions, conditional commits, retry receipts, and explicit failure cases.

Implemented in source · Evaluation access only

Your application owns domain meaning and external-effect idempotency.

Review correctness and ownership →
Related evidence

ML engineer

Which evidence was supplied, and what changes after a correction?

Versioned Context manifests, retained inputs, and synthetic correction fixtures.

Implemented in source · Evaluation access only

Recorded evidence does not prove model consumption or reproducible model output.

Review Context evidence →
Related evidence

AI engineer

How does my AgentCore application integrate and recover accepted work?

Scoped SDK calls, record/retry/correction examples, and durable reconciliation.

Implemented in source · Evaluation access only

Private SDK. Your runtime owns execution and uncertain external effects.

Review SDK integration →
Related evidence

Real NFL data

Inspect a result and the records behind it.

Choose one of five captured NFL games. See its final score, sportsbook-specific closing spread and recorded against-the-spread result, then open its source evidence. These dated public captures do not establish a live Kam State read or correction history.

Dated public NFL snapshot · Dated public NFL captures from October 26, 2026. Not a live feed.

Explore real NFL resultsReview a software-release contract example

Fasting Free · First-party case study

A free timer. A real state workflow.

Fasting Free starts in the browser and adds account saving when the user chooses. The app uses a pinned Kam Rust kernel to check proposed state. The hosted History service is a separate product.

Read the Fasting Free case study
Browse all seven capabilities

Explore by capability

Seven questions about the same State.

Interactive teaching examples—not live customer features. Each view shows its availability and evidence boundary.

Implemented in source

Versioned History

A result changed. What did we use before?

Read this State contract →Planned · not available

Shared records

My agent stopped. What work survives?

Read this State contract →Implemented in source

Inspect inputs

Which exact inputs belong in this request?

Read this State contract →Planned · not available

Track dependencies

What did each step read, and what did a change reach?

Read this State contract →Implemented in source

Read permissions

Can another agent read this record?

Read this State contract →Planned · not available

Reuse recorded work

Why are we doing the same work again?

Read this State contract →Implemented in source

Retry and restart checks

A reply was lost. What was accepted?

Read this State contract →
Review the product layers and their availability

Progressive adoption

Evaluate the foundation. Review the roadmap.

  1. Kam Core

    Implemented in source · prelaunch

    Record, retry supported writes, correct, and read retained exact History and bounded State. SDK distribution and hosted access are not generally available.

  2. Managed State & Context

    In development · not hosted

    Prepare versioned evidence for the next agent, track dependencies, and reconcile stale results with explicit authority.

  3. Managed Workflows

    Product direction · not available

    The proposed workflow layer would define parent-child jobs, execution windows, adapters, and recovery rules. It would identify eligible work from accepted State; the chosen runtime would execute it.

Review the deployment and ownership boundaries

Illustrative designs, not customer deployments. Exact History and bounded State contracts exist in source; general payload metrics, watch, and source connectors remain planned.

  1. Your agents keep running on AgentCore

    Runtime, Gateway, Identity, Policy, and Memory stay as they are. Kam never runs agents or calls tools.

  2. Your app records results in Kam

    Through the History API. An identical supported retry adds no duplicate accepted revision while its evidence is retained; a correction adds a version.

    Implemented in source

  3. Agents read exact versions

    Through the Kam SDK: one exact version, a pinned list, or the current View. Not on npm yet.

    Implemented in source

  4. Optionally publish to AgentCore Memory

    Built, off by default, and not live-tested.

    Implemented · default off

  5. Planned purchasing channel: AWS Marketplace

    Planned. No listing or availability date is announced.

    Planned · not available
More design patterns across industries

SaaS customer success

Which high-value accounts have become at risk since yesterday?

State
Customer · Subscription · Usage · Support tickets
Derived
MRR · Churn risk · Customer health
On AgentCore
Customer-success agent. Runs on AgentCore Runtime, reads the at-risk view, and decides who to contact. Kam records the outcome and the version it read.

Release and incident operations

Is this release still safe to promote?

State
Deployments · Test results · Security findings · Latency
Derived
Deployment readiness · Service health
On AgentCore
Release or incident agent. Runs on AgentCore, reads readiness for the exact build, and decides. Kam records which build and test versions it read.

Commerce operations

Which orders need attention right now?

State
Orders · Inventory · Shipments · Customers
Derived
Stockout risk · Fraud risk · Customer value
On AgentCore
Support or operations agent. Runs on AgentCore and reads the order State your application records. Your application owns source access and decides what happens next.
Planned design: update only dependent metrics

Illustrative data, not a measured saving.

Planned metric dependency graph (synthetic). In this planned design, subscriptions changes; mrr, arr, businessHealth would be recomputed because they read it; churnRate, dailyActiveUsers, p99Latency, supportSla would be reused.

  • subscriptions: changed
  • cancellations
  • usageEvents
  • requestLatency
  • supportTickets
  • mrr: recomputed
  • arr: recomputed
  • churnRate: reused
  • dailyActiveUsers: reused
  • p99Latency: reused
  • supportSla: reused
  • businessHealth: recomputed
  • executive agent: application decides
  • subscriptions → mrr
  • mrr → arr
  • cancellations → churnRate
  • usageEvents → dailyActiveUsers
  • requestLatency → p99Latency
  • supportTickets → supportSla
  • arr → businessHealth
  • churnRate → businessHealth
  • supportSla → businessHealth
  • businessHealth → executive agent (watch)

Result: In this planned design, a businessHealth change would notify its subscriber. Your application would decide whether to run the executive agent; the other 4 metrics would not notify their subscribers while their inputs remain unchanged.

Synthetic example of the planned metrics model. Counts are derived nodes in this diagram (3 of 7 recomputed, found by graph reachability from the changed input), not a measured benchmark.
What stays in your systems of record?

What stays in your databases, and what Kam stores.

Keep your existing databases and services as systems of record. Kam stores the State your agents on AgentCore reuse across turns, with the exact versions behind it.

Keep in your existing systems

  • Transactions and source-of-truth writes
  • Full event and log archives
  • Analytics and ad-hoc warehouse queries
  • Document and vector search

Put in Kam

  • Recorded results agents share
  • Supported derived State with recorded evidence
  • Bounded Views for one agent or task
  • The exact revisions an application recorded as inputs

Read the SDK and toolkit examples →

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 evaluationRead the evaluation scope