Composable AI Agent Infrastructure: Build Modules You Can Replace

Suppose an AI agent platform needs to replace its wallet provider. In a genuinely modular system, that change should affect signing and account operations. It should not force the team to rewrite agent identity, merchant discovery, x402 payment handling, settlement reconciliation, and every policy that limits spending.

Many stacks fail this test. They connect several products, but provider-specific account IDs leak into business logic. Payment callbacks double as settlement records. An identity profile stores the merchant address without a freshness rule. A wallet SDK decides both whether an action is allowed and how it is signed. The components are integrated, yet they are not composable.

Composable AI agent infrastructure requires more than plugins. It requires stable application-level semantics around four changing capabilities: wallets, identity, payment, and settlement. Each module can keep its native strengths, but the system must preserve intent, authority, state, and recovery when modules are added, removed, or replaced.

Composability Begins With A Change Boundary

A modular diagram can show four neat boxes and still hide a monolith. The useful question is not whether each box has an API. It is what must change when one box changes.

Consider four routine upgrades:

• move from one wallet custody model to another;

• add a second identity registry or reputation source;

• support a new x402 payment scheme or asset;

• route settlement through another network or facilitator.

If any of these changes alters merchant order logic, task budgets, fulfillment records, or historical transaction interpretation, the architecture has hidden coupling.

The boundary should be defined by business meaning rather than provider vocabulary. The application understands an authorized action, a resolved agent, a payment requirement, a payment attempt, a settlement observation, and a delivery outcome. An adapter translates those meanings into a provider's accounts, registries, payloads, transaction states, and errors.

This does not make every provider interchangeable. Custody systems have different trust models. Identity registries expose different evidence. Payment schemes bind authorization differently. Networks offer different confirmation and reversal properties. Composability means those differences are explicit and contained, not erased.

One Transaction Context Must Cross Every Module

The four capabilities need a common transaction context before they need a common SDK.

That context should identify the agent, task, merchant, protected resource, authorization decision, payment attempt, settlement reference, and delivery. It should also carry deadlines and idempotency information. A minimal envelope might look like this:

commerce_context
  transaction_id
  agent_id
  task_id
  merchant_id
  resource_id
  policy_snapshot_id
  quote_id
  wallet_operation_id
  payment_attempt_id
  settlement_reference
  delivery_id
  expires_at
  idempotency_key

commerce_context
  transaction_id
  agent_id
  task_id
  merchant_id
  resource_id
  policy_snapshot_id
  quote_id
  wallet_operation_id
  payment_attempt_id
  settlement_reference
  delivery_id
  expires_at
  idempotency_key

commerce_context
  transaction_id
  agent_id
  task_id
  merchant_id
  resource_id
  policy_snapshot_id
  quote_id
  wallet_operation_id
  payment_attempt_id
  settlement_reference
  delivery_id
  expires_at
  idempotency_key

Not every module needs every field. The wallet does not need to understand the seller's reputation algorithm. The identity registry does not need to own a payment attempt. But every emitted event should retain the transaction identifier and the references required to reconstruct why the action happened.

The context must be immutable where intent matters. If the destination, amount, asset, network, resource, or deadline changes, the system should create a new authorization version instead of silently editing the old one. Otherwise, a wallet can sign a valid payload that no longer represents the policy decision.

Use provider IDs as references, not as the primary application identity. A provider account ID can change during migration. The platform's agent and transaction IDs should remain stable enough to correlate the old and new systems.

Put Provider Behavior Behind Capability Adapters

An adapter is useful only if it owns a real translation boundary. Wrapping every SDK method with a method of the same name adds code without reducing coupling.

A capability adapter should normalize five things:

1. Commands: the smallest typed actions the application can authorize.

2. Evidence: signatures, registry records, payment proofs, receipts, and confirmations.

3. State: a compact application state plus the unmodified native state.

4. Errors: retryable, terminal, policy-denied, expired, disputed, and unknown outcomes.

5. Queries: a durable way to recover state after callbacks or processes are lost.

For example, a wallet adapter might expose prepare, authorize, sign, submit, and getOperation. It should not expose a generic executeAnything method to the agent runtime. A settlement adapter might expose submit, getStatus, and getEvidence, while preserving network-specific confirmations in a native evidence object.

Version these interfaces. Adding a mandatory field, changing amount precision, or reclassifying a status can break policy and reconciliation even when the transport API remains compatible.

Adapters also need conformance tests. A provider claiming to implement getStatus must return an authoritative recoverable result after a lost callback, not merely replay an in-memory event.

Four Capabilities Need Four Different Ports

The modules cooperate, but they should not share ownership.

The separation protects replaceability. A new identity module can change how reputation is calculated without receiving wallet keys. A new wallet can change custody without rewriting x402 resource pricing. A payment provider can add a scheme without redefining what the application considers delivered.

Standards help define some of these ports. x402 provides machine-readable payment requirements at the HTTP layer. ERC-8004 defines Identity, Reputation, and Validation registries for agents. Neither standard eliminates the need for the wallet, application policy, delivery logic, or network-specific settlement interpretation.

The most dangerous interface is an undocumented one. If the payment service assumes the identity system has verified a destination, record that assumption as an input requirement. If the merchant releases content after facilitator verification rather than network confirmation, make that acceptance rule visible.

Orchestration Belongs Above The Modules

Capability modules should execute bounded operations. A separate orchestration layer should decide order, policy, retry behavior, and compensation.

A useful orchestration sequence is:

1. resolve the seller and service identity;

2. obtain the current payment requirement;

3. compare the requirement with task and spending policy;

4. request a wallet operation under the approved scope;

5. submit or attach the payment payload;

6. observe verification and settlement states;

7. release or receive the protected resource;

8. reconcile payment, delivery, and any later remedy.

This layer is where human approval may enter. A low-value request to an allowlisted service may proceed under a budget. A new merchant, unusual destination, high-value action, or changed network can require explicit confirmation. Automatic execution remains bounded by policy; composability does not justify unlimited spending authority.

The orchestrator should not become another monolith. Keep policy evaluation, workflow state, and provider adapters separate enough to test independently. Its job is coordination, not custody, identity issuance, payment verification, or consensus.

GOAT Network AgentKit provides a relevant example of this composition model. Its documented surfaces connect wallet and onchain actions with runtime controls, x402 commerce, and ERC-8004 identity capabilities. Developers can use those surfaces within one agent workflow while retaining application-level policy and state. AgentKit is a toolkit for connecting capabilities, not a substitute for deciding their authorization and recovery semantics.

Capability Discovery Prevents Invalid Combinations

Modular systems can produce configurations that compile but cannot complete a transaction. A wallet may support one network while an x402 requirement names another. A settlement adapter may not understand the selected asset. An identity profile may advertise an endpoint but no supported payment scheme.

Each adapter should publish a machine-readable capability manifest. Useful fields include:

• module name and interface version;

• supported networks, assets, and schemes;

• wallet or custody modes;

• required authorization fields;

• identity and endpoint-binding methods;

• verification and settlement capabilities;

• callback and status-query support;

• refund or reversal support;

• known finality and timeout semantics;

• environment and availability status.

The orchestrator should resolve compatibility before asking the wallet to sign. It can intersect the merchant's accepted payment requirements with the wallet's networks and assets, the settlement adapter's support, and the application's policy.

Do not treat a manifest as proof of live availability. Capabilities can be disabled, rate-limited, or temporarily unavailable. Discovery narrows the valid path; runtime checks still confirm current state.

Payment State Must Preserve Native Evidence

The pressure to normalize state is strongest in payments and settlement. It is also where aggressive normalization causes the most damage.

An application may want a small state machine:

quoted -> authorized -> submitted -> verified -> accepted
                   \-> denied
submitted ---------> unknown -> reconciled
accepted ----------> delivered
accepted ----------> remedy_pending -> refunded_or_credited

quoted -> authorized -> submitted -> verified -> accepted
                   \-> denied
submitted ---------> unknown -> reconciled
accepted ----------> delivered
accepted ----------> remedy_pending -> refunded_or_credited

quoted -> authorized -> submitted -> verified -> accepted
                   \-> denied
submitted ---------> unknown -> reconciled
accepted ----------> delivered
accepted ----------> remedy_pending -> refunded_or_credited

This is useful for workflow control, but it cannot replace native evidence. verified might mean that a payment payload satisfies a scheme. submitted might mean that a facilitator accepted a request. accepted is the merchant application's decision to proceed. A network confirmation or bridge state has its own source and security meaning.

Store both the normalized state and the raw provider response. Record who produced the state, when it was observed, and which rule converted it into an application transition. If the rule changes, historical transactions must remain explainable.

This distinction matters in GOAT-related flows. GOAT Network provides programmable execution and documents Bitcoin-secured infrastructure including a BitVM2-based bridge design. Fast execution-network confirmation, an application's x402 acceptance state, a bridge operation, and Bitcoin finality are not synonyms. A modular settlement adapter should expose those boundaries rather than flatten them into one settled flag.

The Swap Test Reveals Hidden Coupling

Before calling the architecture composable, replace one module in a staging environment. A diagram review will not reveal every dependency.

Use seven checks:

1. Configuration: Can the new module be selected without editing business workflows?

2. Identity continuity: Do agent, merchant, and transaction references remain stable?

3. Policy continuity: Do the same spending and trust rules still receive equivalent inputs?

4. Evidence continuity: Can support staff inspect what was signed, verified, and confirmed before and after migration?

5. Recovery continuity: Can an operation started under the old module still be queried and resolved?

6. Error continuity: Do retry and terminal outcomes preserve their meaning?

7. Rollback: Can new operations return to the old module without corrupting in-flight transactions?

The fifth check is commonly missed. A wallet migration may be simple for new payments while old transactions still need replacement, cancellation, or receipt lookup. An identity migration may preserve current profiles but lose historical metadata versions used by policy. A settlement migration may process new transfers but leave refunds tied to the original rail.

Run the swap test with failures, not only successful requests. Time out after signing. Lose a callback. Change an identity controller. Return a payment success with a failed delivery. Restart the orchestrator while state is uncertain. Composability is demonstrated by recovery behavior.

Modular Failure Must Not Become System-Wide Ambiguity

Modules fail independently, but customers experience one transaction. The platform needs failure containment without losing the end-to-end narrative.

Three practices help.

First, make every command idempotent or explicitly non-idempotent. A retry after a timeout must not create a second authorization, payment, or delivery unless the product intentionally permits it.

Second, distinguish unavailable from unknown. Unavailable means the module rejected or could not start the operation. Unknown means the operation may have happened but the platform lacks authoritative state. Unknown requires reconciliation before retrying an irreversible action.

Third, assign compensation outside the failed module. A payment adapter can report that value moved. It cannot decide whether a failed API response should be retried, credited, or refunded. The merchant's product contract owns that remedy, using evidence from payment, settlement, and delivery systems.

Observability must cross module boundaries. Trace one transaction through identity resolution, policy, wallet operation, x402 exchange, settlement observation, and fulfillment. Metrics per provider are useful, but they cannot answer why a paid request produced no service.

Compose Incrementally Instead Of Replatforming Everything

A modular target architecture does not require replacing the entire stack at once.

Start with the boundary causing the most operational risk. If wallet authority is broad, introduce typed actions and policy before changing custody. If merchants are hard-coded, create identity and destination resolution before adding reputation. If payment callbacks are unreliable, build query-based reconciliation before adding another rail.

A practical sequence is:

• establish stable application IDs and the shared commerce context;

• wrap the current wallet and payment flow in narrow adapters;

• externalize authorization policy from signing code;

• add identity resolution and freshness checks;

• separate payment, settlement, and delivery states;

• add capability manifests and compatibility checks;

• run the swap test against the next provider or network.

GOAT Network can enter this architecture as a coordinated set of agent-facing capabilities rather than an all-or-nothing platform decision. AgentKit can supply wallet and onchain action surfaces; x402 can support machine-readable payment flows; ERC-8004 can contribute identity, reputation, and validation references; GOAT execution and bridge infrastructure can provide relevant transaction and settlement evidence for supported workflows.

The application still owns the composition. It decides which modules to activate, which states authorize delivery, how much an agent may spend, how identity evidence affects policy, and what happens when payment and service outcomes diverge. That is the difference between using a stack and surrendering architecture to it.

FAQ

What makes AI agent infrastructure composable?

It is composable when wallet, identity, payment, and settlement capabilities use stable application interfaces and shared transaction references, while provider-specific behavior remains contained. One module should be replaceable without changing unrelated business logic or losing in-flight recovery.

Does a plugin architecture automatically make an agent stack modular?

No. Plugins can still leak provider IDs, status meanings, and authorization assumptions into the application. Real modularity requires versioned interfaces, capability discovery, normalized errors, native evidence retention, and replacement tests.

Can x402 be used independently of a particular wallet or identity standard?

x402 is a broader HTTP-native payment protocol, not a GOAT-exclusive protocol. A specific implementation still needs a compatible payer wallet and payment scheme. Identity can be integrated separately when the application needs discovery or trust policy.

Where does ERC-8004 fit in a composable stack?

ERC-8004 supplies Identity, Reputation, and Validation registries. It can feed agent discovery and trust decisions, but it does not custody funds, authorize spending, process x402 payments, or define settlement finality.

Should settlement be a separate module from payment?

Usually, yes. Payment expresses commercial requirements and authorization, while settlement tracks value movement under a rail or network. Keeping them separate makes confirmation rules, reconciliation, refunds, and network migrations easier to reason about.

Can a modular stack let AI agents pay fully autonomously?

It can automate approved payment workflows, but authority should remain bounded by budgets, destinations, assets, networks, risk rules, and escalation thresholds. Modularity improves control and replacement; it does not remove the need for limits.

Build For The Next Change, Not Only The First Transaction

A working transaction proves that the modules can communicate once. A composable architecture proves that the system can change while preserving meaning.

Keep stable transaction context above providers. Put wallet, identity, payment, and settlement behavior behind narrow adapters. Discover compatibility before authorization. Preserve native evidence beside normalized state. Then test replacement, recovery, and rollback under real failure conditions.

That approach lets a team adopt GOAT Network capabilities where they fit without turning every application decision into a platform dependency. The result is infrastructure that can evolve as wallets, standards, payment schemes, and settlement networks change.