Building Agent Execution Layers

I spent the ETHGlobal Open Agents Async hackathon (April 24–May 6) wiring up something that looks simple on a slide: an agent decides something, runs a workflow, pays for the run, and reads a result from on-chain or DeFi-adjacent systems. The contracts were not what ate the time. The system broke at the execution layer: who is calling, how the run is triggered, and how money attaches to a request.

Takeaway: If your "agent + Web3" demo works in the happy path and fails the moment you add money or permissions, the bug is often not the protocol. It is the execution and identity model around the workflow.

The flow you think you are building

The mental model is clean:

• Agent decides (policy, user intent, or tool output).
• Agent invokes a workflow (HTTP, job runner, hosted function, whatever you named it).
• Agent pays (e.g. 402 / x402-style "pay to proceed" flows for micro-tipping or metered API access).
• Workflow returns a result, possibly after on-chain reads or transactions.

On paper, DeFi and smart contracts sit at the bottom as "the hard part." In practice, the bottom was rarely where we got stuck.

Where it actually breaks

A. Identity: caller vs payer

Workflows need a stable concept of who is running the step. A lot of stacks blur:

• the end user (human or agent principal),
• the runtime identity (the service account / worker),
• the funding source (wallet, prepaid balance, or sponsor).

If there is no clear caller address inside the workflow, you cannot do honest financial or permissioned logic. You can fake it in a demo, but you cannot run margin, limits, whitelists, or "this agent may spend up to X" without separating who acts and who pays. Until that is first-class, every "on-chain step" is guesswork for authorization and for audit trails.

B. Execution fragmentation: UI, API, agent

Same workflow, three doors:

• UI (cookies, sessions, human assumptions),
• API (keys, OAuth, ad hoc headers),
• Agent (tool calls, often different serialization, no browser context).

If those paths diverge in auth, payload shape, or idempotency, you do not have one system. You have three that happen to share a name. An agent is unforgiving: it will hit the one path you did not test, with the one JSON variant your code did not expect.

C. "Payments are broken" (when they are not)

We saw a 402-style error in a microtip flow and chased it as "payments failed." The root cause was a version mismatch between a published package and the source repo we were integrating against. The network and wallet were fine; two builds disagreed on what "success" looks like.

That is not a philosophical problem. It is a reliability problem, and for agents it is worse than for humans. A person retries and curses. An agent loops, burns credits, and corrupts its own state unless failure modes are deterministic and loud.

Takeaway: Agents do not need "smarter" contracts first. They need the same build twice, the same error text twice, and the same payment outcome twice.

D. DevEx that only shows up under automation

• Env vars missing, with an error that points nowhere useful until you have already lost an hour.
• Local works; prod does not, because a scheduler or a secret differs by one character.
• Cron that "should" fire: did not, because the expression was wrongly serialized once, somewhere up the stack.
• Silent partial success: a step returned 200 and still did the wrong thing.

You feel dumb when you find the bug. You should not. These are integration failures, not a lack of intelligence.

The missing piece: an agent execution layer

Smart contracts are about state and rules. The agent still needs a place to run that answers:

• Who is this execution on behalf of?
• How is this run invoked, always?
• How does payment bind to a single, inspectable run?
• What is guaranteed about environment and version?

Call that the agent execution layer: the thin but critical stratum between "LLM with tools" and "chain transaction."

It should provide at minimum:

• Identity-aware execution: first-class caller and payer, propagating through steps.
• Unified invocation: one contract for how UI, API, and agents hit the same workflow, same auth, same bodies.
• Native payment integration: 402 and similar patterns treated as a first-class state machine, not a surprise branch in a handler.
• Deterministic environments: pinned dependencies, obvious builds, and errors that are stable enough to code against.
• Observability: a run id, traceable inputs, and payment receipts tied to that run.

DeFi is strong on custody and liquidity. It is not a substitute for reliable, attributable execution above the wallet.

Why this matters for DeFi builders

Protocols assume a user with a key signs transactions. Agents assume something else schedules work, may pay ahead of time, and may not map one-to-one to a single EOA in your mental model. That gap is not solved by a fancier AMM. It is solved by a consistent execution and identity model in front of the contract calls.

In other words: DeFi can give you the rails. The agent still needs the train schedule.

Still early, not imaginary

The category is new enough that the rough edges are real: mismatched package versions, cron that never fired, 402s that were really configuration drift, workflows without a real caller. That mess is the ground truth, not a reason to be cynical. It is the list you fix when you treat this as systems work, not a one-off demo.

If you are building in this space (Open Agents, or anywhere else)

You will hit these issues. Not because the idea is wrong, but because we are still standardizing the layer above the chain: identity across runs, a single way to call workflows, and money that is bound to a run you can see in logs. The contracts are not the bottleneck. The execution layer is. Get that right, and the rest of the stack stops fighting you.