DEV Community

Jeff
Jeff

Posted on Originally published at powerduck.com

What a Generated A2A Server Is Not

Quick answer: A generated A2A server is a Node 22+ project that exposes JSON-RPC, REST, and gRPC through one HTTP handler, along with a public Agent Card. It is a stateless message adapter, not an autonomous model, a durable task engine, or a push receiver. Persistent tasks and push delivery require a custom executor, and the scaffold is meant for local testing rather than production deployment.

What the generator produces

The output is a runnable project with a clear, narrow job. One HTTP handler carries the three bindings, JSON-RPC, REST, and gRPC, and a public Agent Card describes the service. This gives you a local endpoint that speaks the protocol so requests can be built and debugged without a remote agent.

The value is a fast, consistent surface for testing, not a complete agent runtime.

What it does not provide

Claim Reality
Autonomous model It is a message adapter, it does not reason or decide
Durable task engine It is stateless, tasks do not persist
Push receiver It does not accept or deliver push messages
Production deployment It is a local scaffold for testing

Keeping these limits in view prevents the scaffold from being mistaken for the thing it only imitates at the wire level.

Why stateless matters

A stateless adapter handles a message and returns a response without holding the task between calls. It does not remember a task after the request ends, it does not survive a restart, and it does not coordinate long-running work. That is exactly right for a test surface, where you want predictable behavior and no hidden state.

A real long-running task is different. It needs to be stored, updated as it moves through states, and read back later, and a push flow needs a receiver that can accept deliveries. Neither comes from the generated adapter.

A useful way to work with the scaffold is to point the desktop at it while you build the requests. Because the adapter returns predictable responses and exposes all three bindings, you can confirm the message shape, the version header, and the card discovery before you touch the real remote agent. This catches a wrong method, a malformed body, or a version mismatch early, when the fix is local and cheap. Once the requests are confirmed against the scaffold, you point them at the real agent and run the same assertions. The scaffold does not stand in for that final run, and it does not say how the real agent behaves, but it keeps the setup and contract mistakes from reaching the integration.

Adding the parts it lacks

When you need durable or push behavior, the missing piece is a custom executor rather than a setting inside the scaffold.

  1. Use the generated server to confirm the bindings and the message shapes.
  2. Add a custom executor for persistent tasks and their state.
  3. Add a push receiver if the flow depends on delivery.
  4. Keep the adapter layer thin and put the real logic in the executor.
  5. Do not treat the scaffold as a production agent.

This is the same boundary that keeps a mock or a generated scaffold from being written as a replacement for a real backend. The adapter verifies the protocol, and the executor carries the actual work.

Powerduck states the limits in the generated project rather than implying it is a full agent, so the scaffold stays a testing tool.

Frequently asked questions

Does the generated server run a model? No. It is a stateless message adapter, not an autonomous model.

Can it hold long-running tasks? No. It does not persist state, and persistent tasks need a custom executor.

What bindings does it expose? JSON-RPC, REST, and gRPC through one HTTP handler, plus a public Agent Card.

The bottom line

A generated A2A server is a local, stateless message adapter that exposes the three bindings and a card for testing, not a model, durable engine, or push receiver. It does not persist tasks or accept push, and those capabilities require a custom executor. Treat it as a scaffold that verifies the protocol rather than a production agent, and keep the real work in a separate layer. The line between an adapter and a runtime is what keeps the tool honest. Continue in the A2A guide.

Top comments (0)