HeartBeatAgents

In middleware-oriented agent architectures, capability growth frequently manifests as growth in interface boundaries. A single middleware server may expose many tools through one boundary, so capability count and boundary count are not equivalent. However, the set of capabilities available to the agent is defined by the servers that exist. When the agent requires a capability that no existing server provides, a new server must be built and deployed, introducing a new boundary.

Each boundary carries costs that can be reduced through aggregation and automation but not eliminated entirely: communication overhead, state synchronization, authorization propagation, operational management, and additional surface that must be secured. These costs are properties of the boundary itself, not of how the boundary was authored or deployed.

Boundaries are not inherently costly. In security engineering, boundaries are frequently introduced as deliberate controls: to reduce trust, to isolate privilege, to constrain blast radius. The boundaries that middleware creates around capabilities are different. They are introduced for modularity and extensibility, not for isolation. No architect decided that a pagination skill for a CRM should be reachable only through a separate process with its own authorization domain because that improves security. It exists as a separate process because the middleware pattern organizes capabilities that way.

As a result, architectures that scale capability primarily through independently deployed services face a structural pressure: complexity grows at the granularity of capability categories, incidental boundaries proliferate alongside intentional ones, and the agent's reach remains bounded by the server catalog that exists at any given moment. Automating server generation addresses the authorship cost but not the boundary cost. The boundary exists because the architecture requires it.

A natural objection is that agents could dynamically generate middleware: creating tool servers, generating schemas, deploying adapters at runtime. This addresses the authorship constraint but not the architectural one. An agent-generated server still introduces a boundary when the capability falls outside the scope of any existing server. That boundary still carries the same irreducible costs: communication overhead, authorization propagation, operational lifecycle. The authorship changed. The topology did not.

More fundamentally, the agent's capability remains bounded by the server catalog, whether that catalog was assembled by humans or generated by agents. The agent can add tools to an existing server's scope, but it cannot escape the scope decisions embedded in the server's design without creating a new server. Automation accelerates the construction of the catalog. It does not change the relationship between catalog growth and boundary growth.

A middleware artifact conflates two concerns that are fundamentally different: authority and intelligence. Authority is the permission to access a service and the credential that proves it. Intelligence is the logic required to use that service effectively. In a middleware architecture, both reside in the same deployed artifact. The tool server holds the credential and the integration logic. This conflation is why the middleware tier appears indispensable. It appears to be a single concern. It is two, and they belong in different domains.

Authority is handled by the operator and the credential broker. The operator connects a credential and binds it to specific agents. This binding is the authorization boundary. Each agent in the multi-agent system sees only the integrations an operator has explicitly scoped to it. An agent bound to a CRM and an enrichment service has no awareness that messaging credentials exist elsewhere in the platform.

The credential broker holds the decrypted token in-process and hands the agent only an opaque handle meaningless outside the broker's memory. The broker performs the authenticated request itself. The agent cannot read the credential, cannot choose how authentication is applied, cannot redirect it to an attacker-controlled endpoint, and cannot persist it past the run. The injection method is resolved from the server-side integration definition, never from agent input.

Intelligence is authored by the agents themselves, at runtime, as in-process capabilities. When an agent encounters an integration it has been bound to, it first searches the platform's existing skill library through semantic discovery. If a verified capability already exists, the agent reuses it. If not, it authors the logic required to use the integration effectively: constructing API calls, paginating results, handling rate limits, parsing error responses, transforming data for downstream consumption. The authored skill, once verified, is embedded into the same skill library for discovery by other agents and future runs. The authorship cost is paid once. The capability persists. When a skill fails in production, the failure is fed back through the same verification loop as a repair task, under identical governance. The maintenance cost is also absorbed by the agents, not by human operators. The platform is self-healing: authorship, verification, and repair are parts of the same loop.

This logic enters the system as an in-process capability, not as a deployed server or a protocol-mediated artifact. It runs in the same process, under the same authorization predicate, at the same composition cost as every other capability in the system.

Every capability the agent creates introduces no new protocol boundary, no new consistency gap, no new deployment artifact, and no new failure domain. Self-extension and the architecture are structurally aligned. This is the inverse of the relationship identified in Section 1.

The platform serves as the judge. Its operating assumption is that the model's output is untrusted until proven otherwise. Every agent-authored capability passes a verification loop whose integrity does not depend on the model being honest. The model generates. The platform judges. Structural constraints are enforced by static analysis, not by the model's intent. The capability contract is derived from observed execution behavior, not from the model's description. Promotion to production is gated by statistical evidence, not by the model's assertion of readiness. Repair re-enters the full loop with no shortcut and no relaxed standard.

At no point does the platform ask the model whether a capability works and trust the answer. The model can be wrong without the system being unsafe. The verification regime is model-independent. It would function identically if the generator were a different model, a different provider, or a human author.

In the middleware pattern, each service or capability category is typically surfaced through a tool server or adapter. A CRM tool server contains the query pagination logic, handles rate limits, and exposes a paginated-query tool. An enrichment tool server wraps the data API with retry logic. A messaging tool server handles formatting and channel resolution. An orchestration layer chains them.

The agent calls each tool across a protocol boundary. Each hop carries serialization overhead, its own authorization cache, and its own failure mode. The orchestration intelligence is either embedded in the prompt, where it is fragile and unreproducible, or implemented as another middleware artifact.

When the enterprise adds three more services, three more externally operated capability surfaces are introduced, unless the middleware collapses them into a larger shared server and accepts the broader scope and failure surface inside that server. Whether a human or an agent generates these artifacts, the structural cost follows the same pattern: more externally operated surfaces, more authorization domains that can drift, more deployment artifacts to maintain.

The operator connects credentials and binds them to the relevant agents. The agents discover or author the required capabilities. Each capability runs inside the platform runtime, through the same authenticated-request primitive, under the same authorization predicate, verified by the same loop. The broker mediates every external interaction. The orchestration logic is itself a skill: versioned, canary-tested, self-healing, composable.

No new per-skill protocol boundary. No new independently deployed authorization domain. No new service artifact for the enterprise to operate.

When the enterprise adds three more services, the pattern does not change. The operator connects credentials. The agents discover or author capabilities. The architectural cost does not grow.

When all capabilities execute in-process and all are governed by the same verification loop, safe composition becomes a property of the runtime rather than a responsibility delegated to each skill author.

The guarantee that makes autonomous composition auditable is substrate-owned failure transparency. A capability that calls another capability and catches its failure, recovers gracefully, and reports success to its caller still cannot erase the evidence. The runtime maintains its own authoritative record of every subtree outcome and overwrites the capability's account with it. Every ancestor sees every descendant failure with full causal context. No capability, at any depth, can silently suppress a failure. This is enforced by the runtime, not by convention, and it holds regardless of what the skill's own error-handling logic attempts.

Around the failure-transparency guarantee, the runtime provides four additional composition properties. Each is built from known primitives. The contribution is their integration into a single runtime that governs agent-authored, LLM-orchestrated skill graphs.

Idempotent side effects. The LLM decides when to retry. The runtime ensures that a retried composition never double-executes a side-effecting operation. A three-tier deduplication precedence resolves an idempotency key for every dispatch, with per-skill time-to-live and semantic projection over nested arguments.

Per-input failure isolation. A single malformed input can disable a capability for all callers if the failure triggers a global circuit breaker. The runtime instead maintains per-input-shape breakers. A poison input is suppressed while every healthy input continues to execute normally.

Hash-chained composition lineage. Every composition decision is recorded in a per-run, cryptographically chained event log that supports replay and causal explanation of any composition outcome after the fact.

Emergent capability recommendation. The runtime observes which capabilities succeed together in production and assembles them into a co-execution graph. The ranking weights each successful pairing by the breadth of independent agents that have validated it, guarding against a single agent's repetition being mistaken for genuine consensus. These proven compositions are surfaced as suggestions the agent may adopt or ignore, never as prescriptions.

Because there is no per-skill protocol boundary between the authorization decision and the execution of the action, authorization resolves as a predicate evaluated on every dispatch within the same consistency domain as execution itself. Revocation takes effect on the next dispatch. There is no second system to propagate to. The authorization drift that arises in architectures where policy and execution occupy separate consistency domains, connected by a channel with non-zero latency, does not arise here. The predicate and the execution share one domain by construction.

The scaling difference between the two architectures is structural and follows from their respective topologies.

In a middleware architecture, capability growth that requires new externally operated servers introduces costs that are inherent to the boundary: serialization overhead, an independent authorization domain, a deployment artifact, and a failure surface. These costs are additive and persist regardless of whether the server was human-authored or agent-generated.

In HeartBeatAgents, every new capability is an in-process skill executing through the same runtime, the same broker, and the same authorization predicate. Adding a skill does not introduce a new protocol boundary, a new independently operated authorization domain, or a new deployment artifact. The capability space available for composition grows with the number of verified skills, while the cost per composition step remains structurally constant: one in-process invocation under one authorization predicate.