The representation problem underneath every agent system
Before a system can coordinate agents, retry their work, or hold them to account, it has to answer a plainer question: what can each agent actually do, and how is that written down? Most agent systems answer implicitly. A tool is a function registered in code. A capability is a line in a prompt. A data source is a connection string in config. The description of what an agent can do is scattered across the very artifacts that use it, and it exists in no single place you can point to, hand to another system, or compare against last week's version.
That scattering is the quiet source of a surprising number of production problems. Two teams build the same capability twice because neither could discover the other's. An agent's behaviour changes because a tool it depends on changed underneath it, and nothing recorded that the dependency existed. A capability works in one environment and fails in another because the description of it lived in local config that never travelled. These are ordinary failures, and they are the everyday cost of representing capability implicitly.
Covia's answer starts by making the representation explicit and giving it a name. In Covia, capability is an asset, and the asset model is how the system represents what agents, tools, and data can do so that the rest of the platform has something concrete to coordinate.
What an asset is
An asset is a content-addressed description of what an agent can do. It is a first-class object in the system, with an identity derived from its content, that describes a capability, a tool, a dataset, or a composed pipeline in terms the Grid can reason about. An agent does not hold its capabilities as private implementation detail. It publishes them as assets, and those assets become the unit the platform discovers, versions, composes, and governs.
Three design decisions define the model: assets are content-addressed, assets are versioned, and assets are composable. Each decision solves a specific problem that implicit representation leaves open.
Why content-addressing?
The first decision is that an asset's identity comes from its content. Hash the description of the capability and the resulting fingerprint is the asset's address. Change anything about the description and the address changes with it.
The reason to do this instead of assigning names or sequential IDs is that content-addressing makes identity independent of location and authority. A named registry needs an owner, a server, and a policy for who may claim which name. A content address needs none of that. The same capability described the same way produces the same address on any node, computed by anyone, with no coordination. Two teams that independently describe the identical tool arrive at the identical address and discover they built the same thing, without a central registry ever mediating the fact.
Content-addressing also makes tampering evident by construction. If an asset's address is a hash of its content, you cannot alter what the asset claims to do while keeping its address. The address is a commitment to the exact description. Anything that references an asset by address references a specific, immutable description, and can verify it received exactly that. For a system whose purpose is holding agents accountable for what they do, capability descriptions that cannot silently change underneath a reference are foundational.
The cost is that content-addressing feels rigid at first. You cannot edit an asset in place, because editing produces a different asset. That property turns out to be exactly what makes versioning coherent.
Concretely, an asset gets a stable id you can resolve, invoke, and compose:
from covia import Grid
venue = Grid.connect("https://venue.covia.ai")
# Register a capability as an asset; the venue assigns it a stable id.
asset = venue.register({
"name": "summarise_invoice",
"description": "Summarise an invoice document",
"content-type": "application/json",
})
print(asset.id)
# An operation asset can be invoked directly by id.
op = venue.get_asset(asset.id)
if op.is_operation:
result = op.run({"invoice_id": "inv_123"})Versioning without overwrites
Because an asset is immutable and addressed by content, a new version of a capability is a new asset with a new address, leaving the old one untouched. The previous version keeps existing at its own address. Nothing that referenced it breaks.
This inverts the usual failure mode of capability management. In a system where a tool is a mutable registry entry, upgrading the tool changes it for everyone at once, including every agent that was relying on the old behaviour and never asked to move. The upgrade is invisible until something downstream breaks and the investigation slowly discovers that a dependency shifted. With content-addressed assets, an upgrade publishes a new asset. Agents referencing the old address continue to get the old behaviour, deterministically, until they choose to reference the new one. The migration becomes explicit and per-consumer.
It also gives the system an honest history. The chain of asset versions is a record of how a capability actually evolved, each version pinned to an immutable description. When an agent's behaviour changes, you can ask which asset version it was using and get a precise answer, because the version was never overwritten by the next one. Execution-linked memory and a canonical system of record depend on exactly this: the things an agent acted through have to be pinnable, and content-addressed versioning makes them pinnable by default.
Composition as a first-class operation
The third decision is that assets compose. An asset can be defined in terms of other assets, referencing them by their addresses, so a pipeline that chains three tools is itself an asset whose description names the three assets it depends on.
This matters because real capabilities are rarely atomic. A useful agent capability is often a composition: retrieve, transform, validate, then write. Representing that composition as an asset in its own right, built from addressed sub-assets, gives the whole pipeline a single identity while keeping every dependency explicit and verifiable. The composed asset's address depends on the addresses of its parts, which means the composition is pinned end to end. You cannot swap a component underneath a pipeline without the pipeline's own address changing to reflect it.
Composition over content-addressed parts also makes reuse safe in a way that copying never is. When a pipeline references a sub-asset by address, it gets that exact capability, immutable and verified, no matter who authored it or where it runs. A capability built by one team can be composed into a pipeline by another with no risk that the borrowed piece will shift underneath the borrower. The dependency is a precise reference to an immutable description, so reuse does not import a moving target.
Discovery across the network
Making capability explicit, addressed, and immutable pays off most at the level of discovery. Because an asset is a self-contained description with a location-independent address, it can be published and found across the network rather than trapped inside the one codebase that defined it.
This is what turns a pile of individual agents into something a management layer can actually manage. When every capability an agent offers exists as a discoverable asset, the platform can answer questions that implicit representation makes impossible. What capabilities exist in this system. Which agents provide them. What a given pipeline depends on all the way down. Where a specific capability is used, so that the effect of changing it can be understood before it changes. None of these questions have good answers when capability lives in scattered config. All of them have precise answers when capability is an addressed, discoverable asset.
Discovery also changes the economics of building. In a system where capabilities are discoverable assets, the default first move when you need a capability is to look for the asset that already provides it, because finding it is possible. The scattering that makes teams rebuild the same tool repeatedly is a discovery failure at root, and an explicit asset model removes the excuse for it.
Assets and boundaries
An explicit capability model is also what makes governance precise. If the platform is going to enforce what an agent may and may not do, it needs an exact object to attach that enforcement to. Assets are that object.
A boundary is an execution limit, a defined edge an agent cannot cross without explicit authority. Boundaries are far easier to state and enforce when the things being bounded are addressed assets. An agent's scoped authority can be expressed as the specific assets it is permitted to invoke, named by address, verified at execution. A capability the agent was never granted is a capability whose asset it cannot invoke, and the enforcement is exact because the reference is exact. Vague authority statements about what an agent is "allowed to access" give way to precise grants over addressed capabilities.
This is where the asset model connects back to the seven execution guarantees. Scoped authority, the canonical system of record, execution-linked memory, deterministic retry: each of them needs to name the thing an agent acted through, and each becomes sharper when that thing is a content-addressed, versioned, composable asset rather than an implicit reference to code that may have changed. The asset model is the representation layer the guarantees stand on.
The decision underneath the decisions
Every choice in the asset model traces back to one commitment: the description of what an agent can do should be an explicit, verifiable object in the system, with an identity that cannot drift. Content-addressing gives it an identity from its content. Versioning keeps every identity stable across change. Composition lets identities build on identities. Discovery lets them be found. Governance attaches to them precisely.
The alternative, which most systems live with, is to leave capability implicit and pay for it later in duplicated work, silent dependency shifts, and audits that cannot reconstruct what an agent acted through. Making capability a first-class asset moves that cost forward, into the design, where it can be paid once.
The open question the model raises is worth sitting with as agent systems grow. If a capability is only real to the platform once it is described as an asset, then the quality of everything above it, coordination, governance, accountability, depends on how faithfully agents describe what they can do. What does a system owe its own users when an agent's declared assets and its actual behaviour drift apart, and where should that gap be caught?