AI Agents in Production: What Actually Works

The gap between "we have an agent" and "we have a reliable agent" is collapsing in one direction only: toward higher expectations and harder production constraints. What's happening this week across the practitioner ecosystem is less about new models and more about new infrastructure. The tooling layer is maturing fast, and the failure modes are getting clearer.

Stripe's Minions and What 1,300 PRs/Week Actually Means

Stripe claims their internal AI agents, called Minions, are autonomously merging more than 1,300 pull requests per week. If accurate, this is the clearest signal yet that code review automation has crossed from experiment to load-bearing infrastructure.

The Number Matters Less Than the Architecture It Implies

To merge PRs autonomously at that volume, you are not running a single LLM call against a diff. You need a system that can parse repository context, apply organizational conventions, assess test coverage, make a judgment call about safety, and take an irreversible action. That is a multi-step agentic pipeline with real downstream consequences. The failure rate at scale matters enormously here, and Stripe has not published it. They claim 1,300+ merges per week; they do not say how many PRs were reviewed and rejected, how many false positives required human rollback, or what the error taxonomy looks like.

Still, the production signal is real. Stripe runs one of the most complex financial engineering orgs on the planet. If they are comfortable with autonomous merge decisions at this volume, the trust threshold for agentic code tooling has moved. Teams still debating whether to give an agent write access to their repo are now one quarter behind the curve.

Guardrails Matter More Than The Merge Button

Practically: if you're building internal dev tooling, the question is no longer "can an agent review code" but "what guardrails do you need before you give it the merge button." Audit logging, rollback hooks, and a confidence threshold below which the agent escalates to a human are table stakes, not optional.

What 138 Production Deployments Actually Look Like

A new paper reviews 138 recorded practitioner conference talks on deployed LLM-driven agentic systems. This is the methodological approach worth trusting: not a survey of intentions, not a lab benchmark, but an analysis of what engineers actually shipped and presented publicly.

ReAct and Plan-and-Execute Are Dominant, Not Experimental

The paper identifies recurring architectural patterns across industrial deployments. The practitioner consensus has converged around a small set of architectures. ReAct (reasoning plus acting in an interleaved loop) and plan-and-execute patterns appear repeatedly, not because they are theoretically optimal but because they are debuggable. Engineers can trace why an agent took a specific action, which matters when something goes wrong at 3am.

DAG-based orchestration is also common in multi-agent setups, where separating the planner agent from executor agents gives teams a cleaner boundary to instrument and test.

Debuggability Beats Theoretical Optimality Every Time

The technologies in use are exactly what you'd expect: LangGraph, AutoGen, and custom orchestration frameworks built in-house. The paper's most useful contribution is confirming that bespoke orchestration is not a sign of immaturity. Many production teams have good reasons to avoid off-the-shelf frameworks once scale and reliability requirements tighten.

Practically: if you are picking an architecture today, optimize for traceability over capability. An agent whose decisions you can audit is worth more than one that claims higher benchmark scores.

Memory Is Still the Unsolved Infrastructure Problem

Two separate pieces this week address the same gap from different angles. The architectural reality is that LLMs do not have episodic memory. Every call is stateless unless you engineer persistence explicitly.

Treating Memory as a Database Is the Wrong Abstraction

The MnemoPay project proposes a memory engine called Mnemosyne that applies Ebbinghaus forgetting curves, spaced repetition, and importance scoring to agent memory, rather than storing everything as undifferentiated vector embeddings. The critique of existing solutions like Mem0, Letta, and Zep is pointed: they treat memory as a database. A database does not forget. Human cognition does, deliberately, because not all context is equally relevant across time.

This is an open-source project, not a peer-reviewed result. The 391 tests cited are a good engineering hygiene signal, not an independent benchmark. The neuroscience framing is compelling but the production validation is not there yet.

Forgetting Is The Feature, Not The Bug

The three-layer memory architecture proposed in a separate piece this week (short-term conversation buffer, long-term retrieval, plus a routing layer that decides which to query) is a cleaner engineering pattern for most teams. The conversation buffer managed as a token-limited deque is a concrete implementation detail: you drop oldest context first, you enforce a ceiling, and you make the flush behavior explicit in your code rather than relying on the framework.

The agent that forgets correctly outperforms the agent that remembers everything, because context pollution kills reasoning quality faster than context loss does.

Practically: if you are building agents with sessions longer than a few exchanges, implement explicit memory routing now. Decide what goes to long-term store, what stays in buffer, and what gets dropped. Do not let the framework make that decision silently.

Economic Identity and Security Surface Are the Next Production Crises

Two emerging areas are getting infrastructure attention that they have not historically received. Both are underweighted in most team's current agent designs.

Agents Without Wallets Are Economically Dependent by Design

The wallet infrastructure conversation is early but structurally important. Current AI agents cannot enter into economic relationships autonomously. They cannot pay for an API call from a third-party service, purchase a dataset mid-task, or stake tokens as part of a protocol interaction. Projects like WAIaaS are building REST API surfaces specifically for agent-to-wallet interaction, and the Model Context Protocol (MCP) is being positioned as a self-discovery mechanism that lets agents introspect their own capabilities and financial state at runtime.

This matters architecturally because it changes how you design agent authorization. An agent with its own wallet is an agent with its own resource constraints and its own audit trail. That is a better security primitive than an agent that inherits ambient credentials from its host process.

Healthcare Is Where the Security Failures Will Be Expensive

The security analysis of healthcare AI agents is not theoretical. Agents that interact with Electronic Health Records and Protected Health Information have an exposure surface that passive chatbots do not. The risk taxonomy is specific: PHI leaks through over-collection of patient context, permission bypass through prompt injection, unsafe actions taken on brittle EHR integrations, and audit gaps that make compliance failures invisible until they are expensive.

Google's ADK for Go 1.0, released this week, is the framework-level response to some of this. It ships with observability tooling, plugin architecture, and human-in-the-loop controls designed for production. The human-in-the-loop mechanism is the critical one: for high-stakes domains, an agent that can escalate to a human before taking an irreversible action is not a feature, it is the minimum viable safety design.

Your Agent's Tool Surface Is Your Liability

Practically: before you deploy an agent in any regulated domain, map every tool in its tool surface to the data it can touch and the action it can take. Scope permissions to the minimum required. Log everything. Treat prompt injection as your primary threat model, not hallucination.

Sources: Medium: AI Agents (April 2, 2026), ArXiv cs.SE (Software Engineering & Coding Agents) (April 2, 2026), Dev.to: AI tag (April 1, 2026), DEV.to (April 1, 2026), Dev.to: LLM tag (April 1, 2026), NewsAPI (April 1, 2026)