Infrastructure — ports & adapters

The agent loop is infrastructure-agnostic on purpose. agentfootprint owns the reasoning — context engineering and the ReAct loop — and exposes a small set of ports for everything that touches your infrastructure. An adapter implements one port for one backend. Swap the adapter, keep the agent.

The translation boundary

Three layers, and keeping them apart is the whole design.

A port is written in the vocabulary every backend already has — an identity, an entry, a cursor, a request, a reply, a session id, an event. Nothing else. The hosting ports say it out loud:

The rule these types are written under: no runtime, product or protocol gets a field, a name or an assumption here. A port shaped around one provider's request envelope stops being a port and becomes that provider's SDK with extra steps, and every later adapter pays for it.

An adapter is the vendor layer, and the only place a vendor SDK is allowed to appear. It is lazily required, declared as an optional peer dependency, and refuses by name when its SDK is missing — so the main bundle stays lean and you install only what you use.

A strategy is the choice you make inside a port once the adapter is picked: which memory strategy runs, which retrieval rule ranks, which detach driver ships telemetry, which durability mode writes a session. Strategies are about behaviour; adapters are about backends. Confusing them is how a "swap the database" ticket becomes a rewrite.

The ports

The agent wires ports, not vendors:

const agent = Agent.create({ provider, model, credentials }) // LLM + credential ports
  .memory(defineMemory({ store }))                            // memory-store port
  .toolProvider(tools)                                        // tools port
  .build();

One decision table

Start from what you are trying to do, not from which cloud you are on.

Dev → prod is one line per port

The promise: mock-first locally, real infra in prod, and the agent code in between never changes.

// dev — $0, offline, deterministic
const store = new InMemoryStore();
const provider = mock({ replies: [/* scripted */] });

// prod — same agent, real infra (just these two lines change)
const store = new AgentCoreStore({ memoryId: process.env.AGENTCORE_MEMORY_ID! });
const provider = bedrock({ model: 'us.anthropic.claude-sonnet-4-5-20250929-v1:0' });

How each page below is laid out

Every capability page follows the same four parts, so you can skim to the one you need:

1. The port — the exact members, and which are optional and feature-detected.
2. The adapters — what ships, which peer dependency, and what each one genuinely does not do.
3. The strategy axes — the choices left after the adapter is picked, with a choose-when row for each.
4. Status — shipped, or the honest label. Nothing is called verified that has not been.

Capability pages

• Memory & stores — the MemoryStore port, seven adapters, and what each search() actually ranks
• Sessions in a file — sqliteSessions, the zero-dependency SessionLifecycle
• Identity & credentials — the CredentialProvider port, machine vs user, consent
• Governance & policy — who is allowed to say no, and where each refusal is enforced
• Hosting & runtime — hosts, sessions, durability, and the human-in-the-loop resume loop
• Tools & gateways — the McpClient port and its four transport choices, plus the CodeRunner port: summarize prose, compute data — big tool DATA gets computed outside the context window instead of pasted into it
• Observability sinks — the ObservabilityStrategy port, composition, and delivery timing

Providers

• AWS & Bedrock AgentCore — the first worked provider: every service, its adapter, its door, its peer dependency, and its honest status.
• Google Cloud & Gemini — the third column: the native Gemini provider and Gemini embeddings ship, Cloud Trace is a recipe over standard OTLP, and every other boundary names the port that fills it and the reason it is not an adapter yet.
• On-premises & self-hosted — the column for a deployment that owns its own machines: local models, stores on your disk, NDJSON telemetry, your vault. There is no onPremises() adapter, because on-premises is the absence of a vendor rather than one more of them.

More clouds plug in the same way — each is a set of adapters behind the same ports. Nothing about the ports above knows AWS exists, and nothing about them requires a cloud at all.