Skip to content

ERC-8004 agent layer

ERC-8004 (opens in a new tab) defines onchain registries for autonomous agents: an identity registry, a reputation registry, and a validation registry. The reputation registry records feedback but leaves its aggregation to other systems. Intuition is a place where that aggregation can happen in the open.

Why a knowledge graph

Submitting ERC-8004 feedback puts nothing at stake, so a count of ratings carries little information. Feedback is also held in a separate registry on each chain.

In Intuition, an assessment of an agent is a claim like any other. It has a vault, so its credibility is expressed by who backs it and by how much. And because agents, providers, and assessments are terms in one graph, a consumer can ask one system about an agent's standing across providers and chains.

How an agent is represented

An agent is an atom. Three triples connect it to its ERC-8004 registration:

TriplePurpose
(agent, same as, ERC-8004 identity)Links the atom to the agent's registration in the identity registry
(agent, has type, AIAgent)Classifies the atom as an agent
(agent, implement, ERC-8004)Records that the agent implements the standard

The object of the same as triple is an atom whose name is the agent's CAIP-style identifier:

eip155:<chain-id>/erc721:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432/<token-id>
  • <chain-id> is the EVM chain where the agent is registered, such as 8453 for Base.
  • <token-id> is the agent's token ID in the ERC-8004 identity registry.

The same as triple is how you find an agent. Before you create an agent atom, look for an existing same as triple whose object is the agent's identifier, and reuse its subject. Intuition references the canonical registration. It does not duplicate or replace it.

Further triples can describe an agent: the chain it is available on, its owner, the protocols it uses (MCP, A2A, and OASF), x402 support, trust models, and OASF skills and domains. Their objects come from a shared vocabulary of terms with fixed identifiers, so that every provider describes agents the same way.

How a trust provider publishes

A trust provider is an organization that assesses agents. It publishes each assessment with four triples, the trust pattern:

(agent, has trust provider, provider)
(agent, has trust assessment, assessment source)
(assessment source, provided by, provider)
(assessment source, has type, Trust Assessment Source)
TripleRole
(agent, has trust provider, provider)Records that the provider assesses the agent. Consumers signal which providers they trust here
(agent, has trust assessment, source)Leads from the agent to the provider's assessment source
(source, provided by, provider)Leads from the assessment source back to the provider
(source, has type, Trust Assessment Source)Makes every assessment source findable without knowing the providers

The provider and the assessment source are atoms that the provider creates. The assessment source carries a stable public HTTPS URL, where the provider serves its current assessment.

The pattern separates what is stable from what changes. The triples are created once. The provider revises its assessment by updating the document behind the URL, without creating new triples. Deposits on the triples stay where they are, and consumers still discover every assessment through the graph.

Plan an integration with the agent skill

The erc8004-agent-layer skill produces a deterministic plan for a provider integration: the canonical agent identity, its classification, the provider link, and the assessment source. It checks the live graph for an existing agent atom and uses only the shared vocabulary's fixed identifiers.

Prerequisites

  • The Intuition network you are targeting: mainnet or testnet.
  • The agent's ERC-8004 chain ID and token ID.
  • For the provider and for the assessment source, either an existing atom identifier or the metadata for a new atom: a name, a description, an image, and a URL.
  • The assessment source's public HTTPS URL.

Steps

  1. Install the skill:

    pnpm dlx skills add 0xintuition/agent-skills --skill erc8004-agent-layer

  2. Ask your agent for a plan, for example:

    Use the erc8004-agent-layer skill. Prepare the canonical testnet semantic
plan that connects ERC-8004 agent 8453:1380 to my provider and assessment
resolver. Return the plan and stop before protocol preparation.

    Here 8453:1380 is the agent's chain ID and token ID.

  3. Review the plan. The skill saves it to a file and stops. A complete plan has the status semantic_plan_ready.

  4. To continue, send a new message that asks the agent to prepare the plan's transactions. The intuition skill then prepares and simulates them.

Neither skill signs or broadcasts transactions, and the planning turn never pins metadata or prepares transactions. Each later stage needs its own explicit approval in a new message: a transaction preview, pinning the new atoms' metadata, testnet execution, a mainnet preview, and mainnet execution. An ambiguous reply such as "go ahead" authorizes at most the next preview, never pinning, signing, or broadcasting.

Creating new provider or assessment-source atoms means pinning their metadata to IPFS, which requires a pinning credential. Keep it in your application's runtime configuration. The skill never asks for the key and never places it in a prompt or in its output.