Agent frameworks vs the AI Backend — AgentField Docs
Justy and Cody unpack AgentField's claim that agent frameworks are for authoring behavior, while an AI Backend is for running agents as production services.
Transcript
Justy Cody, this AgentField piece is basically picking a fight with every agent framework without sounding like it wants to pick a fight.
Cody Yeah, and annoyingly, I think the fight is mostly fair. The central claim is clean: authoring agent behavior is different from operating agents as backend services.
Justy Tiny mood check before we do episode eight-twenty and pretend we are normal: my tab situation is fully ungoverned. Which is thematically perfect, because this article is yelling at me about governance.
Cody Your browser is a distributed agent system with no identity layer, no audit trail, and one panicked operator.
Justy Okay, actual argument. Agent frameworks are good when you're wiring prompts, tools, roles, handoffs, structured outputs, memory, and graphs. AgentField says that is the easy part once the agent becomes software other systems depend on.
Cody Right.
Justy And the docs keep coming back to the same product pain: can we build it, scale it, govern it, and prove what it did? That is such an Exploring Next sentence that I hate us a little.
Cody The evidence is mostly architectural, but it is specific. They list the stuff teams end up assembling around the agent: REST APIs, S D K wrappers, validation, auth, versioning, queues, workers, retries, job state, webhooks, discovery, observability, secrets, policy, provenance, signed audit records. That is not a vibes list.
Justy Mm-hm.
Cody Where I buy it is the abstraction sprawl critique. The docs call out chains, graphs, crews, nodes, custom state objects, tool wrappers, and workflow D S Ls that don't map cleanly to a backend. I have seen that exact failure shape. The framework starts as help, then becomes the thing your production system has to translate around.
Justy Their counter is deliberately small, at least on paper: Agent, Reasoner, Skill, Memory, Harness, Execution. Agent is the deployable service node. Reasoner is AI-backed judgment behind an endpoint. Skill is deterministic code. Memory is scoped state. Harness is Claude Code, Codex, Gemini CLI, or OpenCode as a worker. Execution is the runtime record.
Cody Yeah.
Justy That part is the product pitch that lands for me. If you're still figuring out whether the agent works, use LangChain, LangGraph, CrewAI, PydanticAI, LlamaIndex, OpenAI Agents SDK, whatever gets behavior into your hands. If it is now callable by software, running async, touching workflows, or needing approvals, you have crossed a line.
Cody Look at you, being excited about governance again. But yes, Justy, that line is real. My pushback is that the comparison sometimes acts like workflow runtimes are missing the whole point. Temporal already does durable execution, retries, history, recovery patterns. AgentField is saying those primitives are not agent-native, which is plausible, but the docs still have to prove their version is as operationally boring as the mature workflow tools.
Justy Exactly.
Cody Same with the scale language. The docs say the model works for ten agents or one hundred thousand agents. Maybe. But that is where I want hard numbers: scheduler behavior, queue throughput, trace storage costs, policy check latency, failure rates under worker churn. The article argues the shape correctly. It does not settle the implementation.
Justy The useful customer filter is narrower than the headline. I don't think the buyer is every team with an agent. It's the team whose prototype already escaped the notebook and became someone else's dependency. The minute security asks who called what, or a product team needs status callbacks after a forty-minute job, the framework conversation gets kind of quaint.
Cody Oh interesting.
Justy And I like that it does not only dunk on the incumbents. LangChain gets credit for ecosystem and tracing. PydanticAI gets type-safe agents. LlamaIndex gets data-centric retrieval. n8n and Zapier-style builders get connectors. The argument is more: keep those where they fit, then put a service boundary around the thing when it starts acting like infrastructure.
Cody This is round whatever of our load-bearing infrastructure bit. The field keeps naming grand agent architectures, and then the useful part becomes routing, receipts, identity, and audit. I obviously hate how much that sounds like us, but the repo being Apache two point oh and at version zero point one point one seventeen does make it inspectable, at least.
Justy If I were trying it, I would keep the test tiny: one reasoner, one deterministic skill, one harness worker, one async execution that has to retry and leave evidence. Not a cathedral. Just make Claude Code or Codex do something boring, then see if the audit trail is actually useful.
Cody That is the right level. Don't migrate your whole agent stack because a docs page has a confident table. Wrap one ugly production edge and see whether the six nouns reduce glue, or just rename the glue.
Justy Perfect. I am closing the ungoverned tabs now, Cody. No audit record will be produced, which feels merciful.