Skip to main content

Solutions / illustrative designs

From source systems to an agent that acts.

Most teams already have the data. What they lack is durable, scoped, versioned State that each authorized agent can reuse without rebuilding it per turn. These designs show the pattern for three common workloads.

Illustrative, not deployed. Illustrative designs, not customer deployments. They use the planned State API and managed connectors, which are not available today. A design-partner evaluation starts from exact History and one bounded View.

The pattern

Four layers, each with one job.

  1. Source systems

    Postgres, DynamoDB, Stripe, S3, and internal APIs stay your systems of record.

  2. Kam State

    The entities agents reuse, with exact versions and the dependencies between them.

  3. Metrics and views

    Derived values and task-shaped views that recompute only when an input changes.

  4. AgentCore agents

    Agents wake on a relevant change, read one bounded view, and act through your runtime.

Three designs

Same pattern, different State.

Each design names the State Kam would hold, what it derives, and which agent acts on the result.

SaaS customer success

Which high-value accounts became at risk since yesterday?

State
Customer · Subscription · Usage · Support tickets
Derived
MRR · Churn risk · Customer health
Acts on it
Customer-success agent

Materialize at-risk accounts once. The agent wakes when an account enters or leaves the view, not on every renewal-date check.

Release and incident operations

Is this release still safe to promote?

State
Deployments · Test results · Security findings · Latency
Derived
Deployment readiness · Service health
Acts on it
Release or incident agent

A new security finding changes readiness for the affected service only. Unrelated services keep their reused State, and the decision records which revisions it read.

Commerce operations

Which orders need attention right now?

State
Orders · Inventory · Shipments · Customers
Derived
Stockout risk · Fraud risk · Customer value
Acts on it
Support or operations agent

Inventory changes recompute stockout risk for the affected SKUs. Support agents read one bounded view instead of joining four systems per conversation.

Why it is cheaper

One change. Only the affected work.

The SaaS design in detail: a subscription change recomputes three derived values and wakes one agent.

1 · Input changes

subscriptionsOne subscription is upgraded.

2 · Recomputed (3)

  1. mrrreads subscriptions
  2. arrreads mrr
  3. businessHealthreads arr · churnRate · supportSla

Reused, not recomputed (4)

  • churnRatereads cancellations
  • dailyActiveUsersreads usageEvents
  • p99Latencyreads requestLatency
  • supportSlareads supportTickets

3 · Result: The executive agent watching businessHealth wakes. Agents watching the other four metrics stay asleep.

Synthetic example of the planned metrics model. Counts are derived nodes in this diagram (3 of 7 recomputed), not a measured benchmark.

What stays where

Kam is the derived State layer.

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

  • Entities agents act on repeatedly
  • Metrics derived from those entities
  • Views shaped for one agent or task
  • The revisions each decision depended on

Start small

Evaluate one workload first.

A design-partner evaluation starts from the implemented History contract and one bounded View, then defines the metrics and views your agents need.

See the evaluation scope →

One workload. A clear acceptance test.

Bring the State your agents depend on.

Discuss your AgentCore workload, your data boundary, and the failure cases an evaluation must prove.

Discuss an evaluationSee evaluation scopePrelaunch. No production commitment implied.