AgentField’s Skill Rename Is Really a Bet on Live Documentation as Agent Infrastructure
AgentField v0.1.88 is a minor release with a useful accusation baked into it: stale templates are a supply-chain bug when agents are the ones writing your agent infrastructure.
The release’s main change, PR #611, renames the bundled coding-agent skill to agentfield and teaches it to fetch live documentation from agentfield.ai/llms.txt, llms-full.txt, and per-page /llm/docs/<slug> before scaffolding. It also adds a CLI introspection surface, removes hardcoded model defaults, trims thousands of stale bundled reference lines, and reframes pattern docs away from recipe worship. AgentField describes itself as “The AI backend,” with APIs, models, multi-agent calls, shared memory, async execution, webhooks, decentralized identifiers, policy, and audit. The release is smaller than that vision, but it attacks one of the right boring problems: agents need fresh operational knowledge, not fossilized examples.
That matters because the agent-framework market is filling with tools that ask coding agents to build systems on top of fast-moving SDKs. If the agent’s bundled context is stale, the output may look plausible while using old signatures, dead defaults, wrong CLI flags, or architecture patterns that no longer match the runtime. A human can search the docs and notice drift. An agent with a confident stale snapshot will happily generate yesterday’s backend.
Live docs are part of the runtime now
PR #611 names three goals: live docs over baked snapshots, removal of pattern bias, and CLI introspection. The old bundled snapshot is still present, but explicitly as an offline fallback. That is the right priority order. If a coding agent is expected to scaffold AgentField projects, it should first read the current docs, current LLM-targeted index, and current per-page guidance. Static snapshots are resilience mechanisms, not the source of truth.
The llms.txt pattern is important beyond AgentField. Framework authors increasingly need to expose documentation in forms that agents can consume without scraping navigation chrome or guessing which tutorial is current. A good agent-docs surface should be concise, version-aware, linked to authoritative pages, and explicit about CLI commands, configuration shape, examples, and migration risks. If your framework wants agents to build with it, your docs are not just developer education. They are machine-readable infrastructure.
This is especially true for AgentField’s claimed domain. The project positions itself less as another chain/DAG authoring library and more as an API backend for reasoners: agents as callable services with identity, queues, retries, deployment, fleet operations, observability, policy, and proof. That kind of system has too many moving parts for a stale scaffolding skill. Model selection, agent registration, knowledge-base discovery, logs, execution inspection, and verification commands need to match the installed CLI and hosted service.
The new cli-toolkit.md is therefore more than documentation cleanup. It points agents toward af doctor, af init, af agent status, af agent discover, af agent query, af agent run, af agent-summary, af agent kb, af logs, af execution, and af vc. The skill prefers commands like af agent kb guide --goal "..." and af agent discover -q "..." over hand-rolled curl. That is the correct instinct: let the CLI be the introspection API instead of making the coding agent reverse-engineer HTTP calls from docs.
Model defaults should not become architecture
Another small but healthy change: AgentField removes hardcoded gemini-2.5-flash references and changes model selection flow to af doctor, ask the user, live-pick from openrouter.ai/api/v1/models filtered for open-weight providers, then use a frozen fallback only when needed. This is the kind of detail that prevents scaffolding tools from smuggling yesterday’s vendor choice into every new project.
Hardcoded model defaults are seductive. They make examples run. They also become accidental architecture. A template that quietly picks one provider, one pricing profile, one context window, or one availability assumption can shape the whole application before the user has made a decision. In agent systems, model choice affects latency, cost, privacy, output format reliability, tool-call behavior, and deployment geography. It should be visible.
The live-pick flow is not perfect — model marketplaces change, open-weight labels can be messy, and “ask the user” is not the same as policy — but it is better than freezing a demo model into the scaffold. Production teams should go further: define approved model pools, fallback rules, budget limits, provider constraints, and when a workflow may call a larger model. AgentField is right to push the skill away from invisible defaults. The next step is making model policy auditable.
Patterns should describe systems, not possess them
PR #611 also reframes pattern documentation. architecture-patterns.md becomes patterns-emerge.md. Named structures like HUNT→PROVE, parallel hunters, streaming, meta-prompting, factory loops, linear refinement cascades, dynamic routers, and reactive enrichment become vocabulary rather than dominant recipes. A new examples-map.md indexes projects in code/examples/* with one-line shape descriptions.
That is more important than it sounds. Agent scaffolding tools often overfit to their favorite architecture: committees, routers, hunter/prover loops, subagent swarms, or whatever looked clever in the launch repo. The result is architecture cosplay. A simple workflow gets three agents because the template knew how to make three agents. A deterministic validation step becomes a “reasoner” because the framework wanted to show multi-agent coordination.
Most production agent systems should be boring. One reasoner, a few typed tools, explicit memory, predictable callbacks, maybe a subagent when delegation actually reduces complexity. Patterns are useful names for recurring structures after they fit the problem. They are dangerous when scaffolding imposes them before the requirements are known. AgentField’s shift from prescriptive pattern bias toward example discovery is a good correction.
There is still plenty to prove. AgentField’s docs make big claims: scaling from 10 agents to 100k, signed audit chains, service-mesh-like design, harness orchestration for Claude Code/Codex/Gemini/OpenCode workers, identity-aware distributed calls, proof, policy, and governance. v0.1.88 does not validate all of that. It improves the skill/docs/CLI scaffolding layer. Builders should treat the broader platform claims as hypotheses and test them with a real workflow: deploy a small service, inspect logs and execution records, break a tool, test retries, verify policy before execution, and check whether generated code stays aligned after a version bump.
The release supports macOS Intel/Apple Silicon and Linux x86_64/ARM64 binaries, with pinned installs via VERSION=v0.1.88. Backward compatibility is preserved through a new Aliases []string field so agentfield-multi-reasoner-builder resolves to the renamed agentfield skill. The PR also trims the bundled references by roughly 5.4k deleted lines and 4k added lines, which is exactly the kind of unglamorous maintenance that keeps scaffolding from becoming a museum.
The editorial read: AgentField is early, ambitious, and not yet proven at the scale its docs describe. But v0.1.88 makes a correct infrastructure bet. If agents are going to build agent backends, then live docs, CLI introspection, explicit model selection, and less template bias are not polish. They are the difference between generated systems that track reality and generated systems that inherit stale assumptions with a straight face.
Sources: AgentField v0.1.88 release, PR #611, AgentField docs, AgentField framework comparison, AgentField GitHub repository