Production Agents Do Not Need Better Demos. They Need Fresh Data, Safe Writes, and Receipts.

A lot of agent postmortems are going to look embarrassingly familiar once teams stop blaming the model. The agent reordered inventory from stale stock data. It closed an incident because one system said resolved while the rollback was still pending somewhere else. It issued a refund against a customer record whose identity mapping was only “probably close enough.” None of that is a reasoning breakthrough problem. It is infrastructure pretending to be context.

InfoWorld’s production-agents piece is useful because it drags the conversation out of demo-land and into the boring guarantees that decide whether autonomy survives contact with production: fresh data, semantic contracts, safe write paths, and lineage. That list sounds less glamorous than “agentic reasoning,” which is exactly why it is probably right. A production agent is not a model category. It is an infrastructure maturity level.

Freshness is not metadata. It is a permission boundary.

The most important idea in the piece is that agents often reason correctly over the wrong slice of state. That distinction matters. If a human sees an inventory count that is twelve minutes old, they may ask whether that is acceptable before ordering more stock. An agent will often treat the value as the world, because the platform handed it the value without the conditions under which the value is valid.

That means “freshness” cannot be a best-effort property buried in a cache layer. Facts need timestamps. Queries need “as of” semantics. Workflows need freshness service-level objectives: this task may use inventory data up to 30 seconds old, that task may use billing data only from the current transaction boundary, another task must degrade to read-only mode if the platform cannot prove recency. Once an agent can mutate state, stale data is no longer a quality issue. It is an authorization issue with nicer typography.

This also changes how teams should evaluate vendor pitches around agent memory. A vector database can help find similar documents. It does not, by itself, know that a device belongs to exactly one site at a time, that a refund requires a settled payment, or that an incident can be marked resolved in PagerDuty while deployment rollback is still incomplete. Embeddings are retrieval machinery. Production agents need entity contracts.

The safe write path is plan, validate, commit — not vibes, then PATCH.

InfoWorld’s strongest operational recommendation is the structured write path: plan, validate, commit. The agent proposes a change set, the platform validates it against current state and constraints, then the commit happens with an audit record tying the action to the evidence that justified it. That pattern should feel familiar because it is how good production systems already work. Agents just make the absence of that discipline harder to hide.

For engineering teams, this means write authority should be introduced as a ladder, not a switch. Start with advisory agents on read paths. Then allow draft tickets, draft pull requests, proposed configuration changes, or remediation plans that require approval. Only after the system can validate idempotency, authorization, reversibility, blast radius, and current state should it get narrow write access. If the agent cannot describe the evidence behind a mutation, it should not be allowed to perform the mutation.

OpenAI’s prompt-injection guidance points to the same conclusion from the security side. Agent systems need source/sink analysis, explicit consent or blocking for dangerous transmissions, and controls that limit damage even when a prompt-injection attempt succeeds. That is not prompt polish. That is application security architecture. The agent may be the visible actor, but the platform is where the risk is bounded.

Lineage is the debugging primitive agents have been missing.

The phrase “debugging becomes archaeology” is painfully accurate. When an agent gives a plausible answer or performs a plausible action, the useful question is not “what did the model say?” It is: which retrieval results were used, which tools ran, which identities and policies applied, what state changed, which constraints were checked, and what evidence was attached at commit time?

That is why lineage matters more than a pretty transcript. A chat log tells you the performance. A lineage record tells you the production system. The difference becomes critical once agents have access to collaboration tools, email, code repositories, identity providers, and internal business systems. Cybersecurity Insiders’ 2026 AI Risk and Readiness data puts numbers behind the discomfort: 73% of surveyed organizations deploy AI tools, but only 7% report advanced governance with real-time policy enforcement. The same report says 94% have gaps in AI activity visibility, and 91% discover what an agent did only after execution. That is not an autonomy strategy. That is a delayed-notification feature for incidents.

The NIST 2026 concept paper on software and AI-agent adoption lands in the same territory, asking for standards around identification, authorization, auditing, non-repudiation, and prompt-injection mitigation. Translation: agents need identities, bounded authorities, durable receipts, and policy enforcement that does not depend on everyone hoping the system prompt has a good day.

The practical checklist is mostly distributed-systems homework.

The uncomfortable lesson is that “agent readiness” looks a lot like platform readiness. Before expanding autonomy, teams should define authoritative sources for critical entities. They should document freshness SLOs by workflow. They should separate retrieval context from write authority. They should add idempotency keys, transactions, row-level access controls, approval thresholds, and rollback paths. They should log tool calls and policy decisions in a way that can be replayed without turning traces into a second sensitive-data warehouse.

That last detail matters. More logging is not automatically safer. Agent traces can contain customer records, security findings, credentials accidentally exposed in terminal output, and proprietary code. The goal is not to store every raw prompt forever. The goal is to preserve enough structured evidence to answer who did what, under whose authority, against which data, with which validation, and what changed as a result.

This is where many “AI-native platform” pitches become both compelling and slippery. A platform that unifies records, documents, graph relationships, time-series events, and embeddings under transactional and auditable controls can genuinely help agents. But no database purchase gives you an operating model. You still need source ownership, context contracts, redaction, workflow-specific policies, approval gates, replay harnesses, and explicit write boundaries.

The teams that do this well will probably sound less magical than the demo teams. Their agents will ask for confirmation when data is stale. They will refuse writes outside scope. They will attach evidence. They will produce boring audit trails. That is the point. Production autonomy should be boring enough to trust.

The take: stop asking whether the model is smart enough to be “production ready.” Ask whether your data, semantics, write paths, and receipts are ready for a non-human actor that never gets tired and never notices when your platform is lying by omission. If the answer is no, you do not have a production agent. You have a demo with a pager attached.

Sources: InfoWorld, OpenAI, Cybersecurity Insiders, NIST