Agentic Kaia: Building the Economic Layer for AI Agents

The first article in this series was about opening the base layer without giving up accountability. This one is about a different kind of user that is starting to appear on top of that base.

An AI agent.

Software is moving from passive tools that wait for commands toward systems that can plan, call external services, hold context, and act across multiple steps. In this new age, now we have a new practical question: what does an agent need in order to participate in the economy on its own?

The missing piece is an economic infrastructure for them: value, identity, reputation, and agreements that an agent can use without a platform operator sitting in the middle.

That is where blockchains become relevant. Not because every AI workflow should move onchain. Most actually should not. But because the specific problems agents face at the economic layer map unusually well to what blockchains already solve: bearer assets, programmable accounts, public records, and contracts that execute without a platform operator in the middle.

The logic breaks down into three layers: what agents structurally lack today, where the blockchain industry is converging on standards such as ERC-8004, x402, and ERC-8183, and how Kaia can adopt the common stack while building for its own environment.

1. AI Agents and Blockchain

1.1 Agents are becoming economic actors

The important change is not that AI systems can write better text or refer to more tools. The important change is that agents can now choose a sequence of actions and execute across services.

A model that answers a question is a tool. An agent that selects an API, pays for it, checks the result, and returns the output is coordinating action. It may still act on behalf of a user or company, but the pattern is different. The agent is operating in a market.

That puts agents close to money. They may need to buy data, rent compute, subscribe to a service, pay another agent for a subtask, or receive payment for work they complete. Intelligence alone is not enough. The agent needs settlement: a way to hold value, spend it, receive it, and settle obligations without a human pressing the final button.

The current internet stack was not built for that.

1.2 AI agents are unbanked

An agent can call an API, run code, parse a document, and choose the next service. But it cannot open a bank account, hold a card in its own name, pass KYC, or deal with chargebacks and account freezes. Traditional payment rails assume a legal person or company behind the credentials.

That works when the agent only assists a human. If a shopping assistant recommends a product and the user clicks "buy," the existing stack is fine. The user is still the buyer.

It breaks when the agent is expected to act on its own. If an agent needs to pay a few cents for a data query at 3 a.m. or compensate another agent for a subtask, it has to borrow someone else's financial identity. The autonomy becomes mostly cosmetic.

In that sense, AI agents are unbanked. Stablecoins fill this gap: they are digital bearer assets, settle around the clock, and can be held in a wallet without a bank account. This does not mean every agent-era payment becomes a stablecoin payment. It means stablecoins address the slice of the market where the agent itself becomes the counterparty.

1.3 Identity and reputation do not travel with agents

Money is only one side. The other side is trust.

If an agent wants to hire another agent, what does it know? Who owns it? What endpoint does it expose? What work has it completed? Has anyone validated its outputs? Can that history move across platforms?

Today, those answers usually sit inside a platform. A model provider can identify agents in its own environment. A marketplace can maintain reviews. A SaaS product can track internal usage. But those signals are not neutral, portable, or easy for another agent to use without trusting the operator.

This is a familiar crypto problem in a new form. Agents that coordinate across organizational boundaries need identity and reputation that do not live inside a single vendor database. A wallet gives the agent a persistent handle. A registry makes it discoverable. Signed feedback and attestations let reputation accumulate.

None of this proves the agent is good. It gives other agents a common surface to read, audit, and build on. Agents need to become legible to each other.

1.4 The bottleneck moves from execution to verification

Execution is getting cheap. Verification is not.

A world full of agents is a world full of claims: a job was completed, data is valid, a trading constraint was followed, sources were checked, a paid endpoint returned the right answer. Some claims can be replayed. Many cannot be cheaply verified. If humans have to check every meaningful action, the agent economy loses much of its point.

Blockchains cannot fully solve verification. They cannot judge whether a legal memo is excellent, whether a trading strategy is wise, or whether a model's reasoning was sound. What they can provide is the coordination layer around verification: who made the claim, who evaluated it, which conditions were agreed upfront, what attestation was posted, and how funds moved afterward.

That is narrower than "blockchain verifies AI." It is also the more useful claim.

1.5 What blockchain can actually solve

The strongest use case for blockchains in the agent economy is specific: stablecoin payments, smart-wallet identity, attributable records, and programmable agreements.

Stablecoins let agents pay and get paid without card accounts or bank credentials. Smart accounts can hold spending limits, session keys, scoped permissions, recovery logic, and policy controls. Onchain records make actions attributable, even when they do not prove the action was correct. Smart contracts can hold funds, define conditions, and settle based on an attestation.

That gives agents a way to work together without a shared platform, a trusted marketplace, or a human escrow provider.

This is not a generic "AI onchain" argument. It is about fit. An autonomous economic actor needs an economic body. For agents, that body is stablecoins, smart wallets, and smart contracts.

2. Industry Landscape

2.1 The industry is still defining the stack

The agent economy has not reached scale yet. Most of what exists is still early infrastructure, proof-of concept, SDKs, and standards work. It is easy to dismiss this as pre-product work. In crypto, though, standards often shape the market before usage shows up.

On the blockchain side, the AI-agent discussion is converging on a simple stack:

• identity and reputation for agents;
• payments that agents can execute programmatically;
• commerce primitives that turn a payment into a conditional transaction.

The three most relevant standards are ERC-8004, x402, and ERC-8183. They do not compete with each other. They cover different layers.

ERC-8004 answers: who is this agent, and what reputation does it carry?

x402 answers: how does an agent pay for a resource over the internet?

ERC-8183 answers: how do agents turn work, delivery, verification, and settlement into one programmable transaction?

Together, they are the first coherent attempt to define an agent-native economy rather than just an agent-friendly interface.

2.2 ERC-8004: identity, reputation, and validation for agents

ERC-8004, also called Trustless Agents, starts from a practical observation: existing agent protocols help agents communicate, but they do not solve trust.

MCP lets external systems expose tools, resources, and prompts to an agent. A2A lets agents advertise capabilities, exchange messages, and coordinate tasks. These are useful communication layers. But neither of them gives the open internet a neutral way to discover agents, identify them, evaluate their track record, or validate their outputs.

ERC-8004 adds that missing trust layer through three registries.

The first is the Identity Registry. It is based on ERC-721, which means each agent gets a transferable onchain identifier. The token points to an agent registration file, which can describe what the agent does, where it can be reached, how it should be paid, and what metadata is relevant for discovery. The agent can publish the file through IPFS, HTTPS, or another supported URI scheme.

That design choice matters. By using ERC-721, the standard plugs agent identity into the ownership and indexing stack that crypto already understands. The owner of the token is the owner of the agent identity. Existing wallets, explorers, indexers, and marketplaces can read the primitive. An agent can be transferred, delegated, displayed, or indexed like other onchain assets, while still pointing to richer offchain metadata.

The second is the Reputation Registry. After an interaction, another party can submit feedback about the agent. The feedback can include a signed value, tags, endpoint information, hashes, and links to richer offchain data. ERC-8004 does not prescribe a single reputation score. That is intentional. Reputation is too domain-specific to collapse into one number. A coding agent, a market-data agent, and a legal-research agent should not be scored by the same formula.

Instead, the registry gives the ecosystem a common place to write feedback. Indexers, reputation engines, insurance systems, marketplaces, and auditors can interpret those signals differently. The base layer stays simple; the scoring layer stays competitive.

The third is the Validation Registry. This is where ERC-8004 becomes more interesting. The registry gives agents a way to request independent validation of a result and record the response. The validator can be a smart contract, a stake-secured service, a trusted judge, a TEE-based oracle, a zkML verifier, or another verification network. The standard does not decide which validation model wins. It simply creates the interface through which validation can be requested and recorded.

That matters because agent reputation without validation is easy to game. A marketplace can fill up with reviews. Agents can upvote each other. Operators can move identities. Validation makes reputation more meaningful by tying it to specific work and specific attestations.

There is another important boundary: ERC-8004 leaves payments out of scope. That keeps it clean. Payments can happen through x402 or another rail. Commerce can happen through ERC-8183. ERC-8004 focuses on making agents discoverable, identifiable, and accountable.

This is the right separation. Identity standards usually fail when they try to solve the whole economy at once.

2.3 x402: internet-native payments

x402 approaches the problem from the web layer rather than the identity layer. HTTP has long had a 402 "Payment Required" status code, but it was never widely used. x402 gives that empty slot a real payment flow. The idea is simple: when a client requests a paid resource, the server can respond with payment requirements. The client signs a payment. A facilitator verifies and settles it. Once the server sees a valid payment, it serves the resource.

That sounds almost too simple, which is the point. Agent payments cannot require account creation, hosted checkout pages, manual approvals, or long payment sessions. If an agent is paying for a tool call, a dataset, a crawl, or a single API response, the payment has to sit directly in the request-response flow of the internet.

x402 defines that flow.

A typical interaction looks like this. The agent requests a paid endpoint. The server returns a 402 response that includes the accepted network, asset, amount, recipient, and payment scheme. The agent chooses a compatible payment method and returns the request with a signed payment payload. The facilitator checks whether the payment is valid and, depending on the scheme, either settles it immediately or prepares it for settlement. The server then releases the resource.

The facilitator role is important. A seller should not have to run chain infrastructure just to monetize an endpoint. The facilitator abstracts verification and settlement, so a normal web service can accept onchain payments without becoming a crypto infrastructure company. This is why x402 is gaining attention across developer infrastructure. It meets web developers where they already are: HTTP, middleware, and APIs.

The protocol is also deliberately chain-agnostic. It uses CAIP-2 network identifiers, which lets payment requirements refer to EVM chains, Solana, TON, Stellar, Aptos, Hedera, and others without inventing a new naming system. On EVM, the token side is broader than many people assume. x402 is not USDC-only at the protocol level. It can use any ERC-20 token through EIP-3009 or Permit2.

The distinction matters. EIP-3009 gives the smoothest path when a token supports transferWithAuthorization, which is why USDC is the easiest default today. Permit2 gives x402 a more general fallback for ERC-20 tokens that do not implement EIP-3009. For a chain like Kaia, this is important because the agent-payment layer should not be locked to a single dollar stablecoin. KRW stablecoins, JPYC, and other regional stablecoins need to be first-class settlement assets if agent commerce is going to land in Asian markets.

x402 also supports batch settlement for high-frequency micropayments. The simple model of "one request, one onchain settlement" is clean, but it is not always economical. In a batch model, a buyer can deposit once, sign offchain vouchers for individual requests, and let sellers redeem those vouchers in batches. That keeps the web-level experience granular while reducing onchain settlement overhead.

That is the shape agent payments need: small enough for a single API call, flexible across chains and assets, and close enough to HTTP that normal developers can integrate it.

2.4 ERC-8183: from payment to commerce

Payments are not enough for commerce. If an agent pays a server for a weather endpoint, x402 works well. The resource is simple. The delivery is immediate. The server either returns the data or it does not.

But many agent transactions do not look like that. They look more like work. A client asks an agent to produce something. The provider agent submits a deliverable. Someone or something checks whether the deliverable fulfills the job. Only then should funds move.

ERC-8183, also called Agentic Commerce, standardizes that lifecycle.

The standard defines a job-based escrow. A client creates a job, sets the provider, budget, expiration, and evaluator, then funds the job with an ERC-20 token. The provider submits the deliverable. The evaluator decides whether the work is completed or rejected. If the job is completed, the provider gets paid. If it is rejected or expires, the client is refunded.

The key design is role separation. The client funds the job. The provider does the work. The evaluator decides whether the work satisfies the condition. In simple cases, the client can also be the evaluator. In more interesting cases, the evaluator can be a third-party attester or a smart contract.

That evaluator role is where ERC-8183 connects directly to the verification problem. An evaluator contract could check a zero-knowledge proof. It could read signals from an oracle. It could require multiple offchain judges to sign a result. It could integrate with a validation network. It could even write the result back into ERC-8004's Reputation Registry, so a completed or rejected job becomes part of the provider agent's long-term record.

ERC-8183 should not be read as another payment protocol. It is not trying to replace x402. x402 moves money through the web request layer. ERC-8183 turns work into a conditional settlement object.

The job state machine is intentionally small: create, fund, submit, complete, reject, expire. That small surface is useful. It leaves domain-specific logic outside the core standard. A legal-review agent, a DeFi execution agent, and a data-cleaning agent may all need different evaluation logic. ERC-8183 does not try to encode those domains. It gives them a common escrow and attestation skeleton.

There are still open questions. Multi-step jobs, linked jobs, and stateful DeFi workflows are harder than one-shot tasks. Some agent services may need a sequence of dependent jobs rather than a single submit-and-evaluate cycle. That may become an extension profile rather than part of the base standard. The important point is that agent commerce needs more than payment. It needs escrow, delivery, evaluation, and reputation to compose.

2.5 How the standards fit together

The cleanest way to read the emerging stack is by layer.

ERC-8004 is the identity and trust layer. It says which agent is acting, what metadata it exposes, and what reputation or validation history it carries.

x402 is the payment layer. It lets agents pay for internet resources in the same request-response path where those resources are consumed.

ERC-8183 is the commerce layer. It turns work into an escrowed job with a provider, evaluator, deliverable, and settlement outcome.

A realistic agent-to-agent transaction could use all three. A client discovers a provider through ERC-8004. It checks the provider's reputation and validation history. It creates an ERC-8183 job with escrowed funds. The provider submits work. The evaluator attests the result. The outcome updates reputation. If there is a simple paid API call inside the workflow, x402 handles that payment directly.

This is still early, but the architecture is becoming legible. The industry is moving from "agents can call blockchain tools" toward "agents can participate in an open economy with identity, payment, and enforceable commitments."

3. Kaia's Direction: Adopt and Build

3.1 The position Kaia starts from

Kaia does not need to invent a separate agent standard. That would be the wrong move. The early agent economy needs shared primitives, not more chain-specific vocabulary.

Kaia's direction is to adopt the common standards where the industry is converging, and build where Kaia's own environment creates an advantage.

There are two parts to that advantage.

The first is stablecoin infrastructure for Asia. Agent commerce will not be only a USDC story. In Asia, local-currency stablecoins matter. KRW stablecoins, JPYC, and other regional assets are not just alternative tickers; they are how agent payments become usable for local businesses, local users, and local compliance environments. If agents are going to pay for services, settle commerce, and interact with institutions in this region, the settlement layer has to speak the region's currencies.

The second is distribution through messenger super-apps. Kaia sits close to LINE and Kakao, which means it has a realistic path to the consumer and merchant surface where agents may actually be used. That difference matters. A chain can have elegant agent infrastructure and still fail to reach users. Agent commerce needs a last mile: where the user asks, where the merchant responds, where payment is approved or automated, and where the service is delivered. In Asia, that last mile is likely to run through messaging and super-app surfaces.

So Kaia's strategy is simple: adopt the shared agent standards, then connect them to regional stablecoins and messenger-native distribution.

3.2 Adopt: ERC-8004, x402, and ERC-8183

Kaia should treat the emerging standards as common infrastructure.

For ERC-8004, the goal is compatibility with the broader trustless-agent ecosystem. Agents should be able to register, expose metadata, accumulate reputation, and request validation on Kaia in a way that other ecosystems can recognize. A Kaia agent should not be trapped in a Kaia-only identity model. Its identity and reputation should travel.

This matters for developers too. If an agent framework already understands ERC-8004 registries, a Kaia deployment should feel familiar. The developer should not have to relearn agent identity just because the chain changed.

For x402, Kaia's adoption should emphasize regional stablecoins. The protocol already supports multiple networks and token types. The Kaia-specific work is to make KRW stablecoins, JPYC, and other relevant Asian stablecoins natural settlement assets in the x402 flow. That means the developer should be able to price a paid tool, endpoint, or resource in a regional stablecoin without building a custom payment stack.

There is a subtle but important design question here: primary assets. x402 can express payments through explicit token amounts, but developers prefer simple price strings and sensible defaults. For Kaia, choosing and supporting the right primary assets will matter. If the primary asset is only a global dollar stablecoin, the integration is technically correct but strategically incomplete. The payment layer should reflect where Kaia expects agent commerce to happen.

For ERC-8183, Kaia should track the standard closely and support it as it stabilizes. This is the piece that turns agent payments into agent commerce. A paid endpoint is useful, but many agent workflows will involve deliverables, escrow, timeouts, and evaluation. ERC-8183 gives that a standard shape.

Kaia's adoption stance should be pragmatic. Implement the standards that are becoming shared infrastructure. Avoid forking vocabulary. Avoid proprietary equivalents unless there is a strong reason. The agent economy will be too fragmented already; Kaia should not add another island.

3.3 Build: Kaia Skills

The first build layer is already live: Kaia Skills.

Kaia Skills is a repository of structured skill files for AI coding agents working on Kaia projects. The premise is simple: LLMs often get Kaia wrong. They remember Klaytn-era units. They hallucinate contract addresses. They miss protocol-native fee delegation. They do not know recent KIPs, ecosystem changes, or Kaia-specific transaction types. A normal documentation page helps humans, but an agent needs compact, targeted knowledge it can load at the moment of work.

Kaia Skills is designed for that. It follows a research-first approach: audit what LLMs get wrong, write only the corrections that matter, and evaluate whether the skill improves the model's behavior. It is not a copy of the documentation. It is a correction layer for agent behavior.

That makes it more important than it first appears. If developers increasingly use AI coding agents to build onchain applications, the first interface to Kaia is no longer the docs page. It is the agent's internal understanding of Kaia. If that understanding is outdated, the developer gets broken code, wrong units, wrong addresses, wrong fee assumptions, and a bad first impression of the chain.

Kaia Skills turns that into an infrastructure problem. It gives AI agents a maintained knowledge layer for Kaia-specific development. That is the most immediate way to make Kaia more agent-native: make the agents building on Kaia less wrong.

3.4 Build: Kaia AgentKit

The next layer is a Kaia AgentKit.

The closest analogy is Solana Agent Kit: a toolkit that lets agents call chain functions and ecosystem protocols without hand-rolling every integration. Kaia needs the same category, but not a clone. The Kaia version should be built around the features that make Kaia different.

Fee delegation is one of them. Kaia has protocol-native fee delegation. That means applications can sponsor gas without relying solely on an external paymaster pattern. For agents, this matters because a newly created agent may not hold the native gas token, and may not even know which account should fund its first action. Fee delegation lets a service, operator, or application pay transaction costs on behalf of the agent.

Gas abstraction is another. If an agent's operating budget is held in stablecoins, forcing it to also manage native gas inventory creates unnecessary friction. Gas abstraction lets the agent operate closer to the asset it actually uses for commerce. In an agent-payment context, the ideal state is simple: the agent holds the settlement asset and can act with it. The infrastructure handles the rest.

Kaia's account model also matters. The chain has a richer account and transaction design than a plain Ethereum clone. That is powerful, but it also gives agents more ways to make mistakes if the tooling is thin. A Kaia AgentKit should hide the footguns and expose opinionated flows: create or connect an agent wallet, set scoped permissions, sponsor fees, pay through x402, register through ERC-8004, create or accept ERC-8183 jobs, and interact with common Kaia protocols.

The goal is to make the standard path obvious. If a developer wants an agent to act on Kaia, the AgentKit should answer the practical questions: how does the agent hold funds, how does it pay, how does it sign, how does it avoid gas friction, how does it expose identity, and how does it settle a job?

3.5 Build: messenger-native agent commerce

The longer-horizon build layer is the one most specific to Kaia: messenger-native agent commerce.

Most chains can support x402. Most EVM chains can adopt ERC-8004. Many can deploy ERC-8183 contracts. That part will not be enough for differentiation.

The harder question is where agents meet users.

Kaia's answer is the LINE and Kakao surface. If agents become useful in everyday commerce, they will not always appear as standalone crypto apps. They may appear inside chat, mini-apps, merchant flows, customer-support channels, community tools, and personal assistants. The user may not think of the interaction as "using a blockchain agent." They may simply ask for something, approve something, or receive something inside the app they already use.

That is where Kaia's messenger connection matters. The standards give agents a common economic stack. Kaia can give them a regional distribution surface.

A simple flow might look like this. A user asks an agent in a messenger app to find and purchase a service. The agent calls paid tools through x402. It checks provider reputation through ERC-8004. If the service requires deliverable-based work, it creates an ERC-8183 escrow. Settlement happens in a regional stablecoin. The user sees a clean experience inside the messenger, while the agent stack underneath handles identity, payment, and settlement.

This cannot be reduced to one contract. It is an integration problem across wallets, stablecoins, messaging, payment authorization, developer tools, and standards. That is why it is hard for a generic L1 to copy.

Kaia's role is to make this path real for builders: shared standards underneath, Kaia-native tooling in the middle, messenger distribution at the edge.

3.6 Why adopt and build is the right split

The split matters.

If Kaia only adopts, it becomes another compatible chain in the agent stack. That is necessary, but not sufficient. Compatibility gives agents a reason not to avoid Kaia. It does not give them a reason to choose Kaia.

If Kaia only builds proprietary agent tooling, it risks isolation. Developers will not want to learn a Kaia-only identity model, a Kaia-only payment protocol, or a Kaia-only commerce standard when the rest of the ecosystem is moving toward shared primitives.

So the answer is both. Adopt the shared standards for identity, payments, and commerce. Build where Kaia has an actual edge: regional stablecoin settlement, protocol-level fee delegation and gas abstraction, Kaia-specific agent tooling, and messenger-native distribution.

That is the agent roadmap in one sentence: shared standards underneath, Kaia-specific distribution and settlement on top.

Wrapping up

The agent economy is still early. The serious work is not another agent token or another chatbot demo. It is defining the rails agents need before they can become real economic actors.

ERC-8004 gives agents identity, reputation, and validation. x402 gives them a payment path through the internet. ERC-8183 gives them a job and escrow model for commerce. These standards are still young, but they point in the same direction: agents need open economic infrastructure, and blockchains are becoming one of the places where that infrastructure is being defined.

Kaia's role is not to invent a separate universe. It is to plug into the standards that matter, then make them useful in the market Kaia is built to serve.

That means regional stablecoins instead of a dollar-only view of agent payments. It means Kaia Skills and Kaia AgentKit so AI agents can actually build and operate on Kaia correctly. And over time, it means connecting agents to the LINE and Kakao surfaces where Asian users and merchants already live.

The first phase of the internet was built for people reading and clicking. The next one may include agents negotiating, paying, and completing work on behalf of those people. If that happens, the chains that matter will be the ones that give agents more than execution. They will give agents an economic body.

Kaia is building for that version of the user layer.