383 posts tagged with "ai-agents"

Your next calibration meeting has a measurement problem nobody wants to name. The packet in front of the committee says one engineer shipped 340 PRs this half and another shipped 90. Five years ago that gap meant something. Today it mostly tells you who has the better agent harness, the more permissive review culture on their team, and the higher tolerance for merging generated code. The number on the slide measures the fleet. The committee is supposed to be evaluating the human.

This isn't a hypothetical drift that will arrive someday. Industry analyses estimate AI now writes on the order of 30% of committed code at companies that have adopted agents seriously, and a longitudinal study of 300 engineers found teams generating 98% more pull requests after agent adoption. Every output metric your review process inherited from the pre-agent era — lines changed, PRs merged, story points, velocity — is now a blended measurement of human judgment and machine throughput, with no attribution boundary between them. Calibration committees are comparing blended numbers as if they were still measuring people.

Ask any infrastructure team to restore the production database to yesterday at 3pm and they will quote you a runbook, an RPO, and a time estimate. Ask the same team to restore the agent to yesterday at 3pm — before it absorbed a batch of poisoned memories, before someone shipped the bad prompt revision, before the reindex that quietly broke retrieval — and you will get silence. Not because the individual pieces lack backups, but because nobody can say what "the agent at 3pm" even means.

That is the uncomfortable discovery waiting for every team running agents that learn: your database has snapshots, your code has git, and your agent — the thing your users actually interact with — has neither. Its operational state is smeared across a vector index, a pile of memory files, a prompt registry, and a set of tool configurations, each versioned independently or not at all. Restore any one of them alone and you don't get yesterday's agent back. You get an incoherent brain.

Here is a migration story that repeats in every team shipping agents. You built your agent on one provider's SDK. Tool definitions live as JSON schemas in the exact shape that provider expects. Tool results get formatted into that provider's message structure. Then something forces a change — a better model ships from a competitor, procurement mandates a second provider for redundancy, an MCP server replaces a hand-rolled integration — and you discover the real inventory of the migration: it isn't one API client. It's every tool definition, every result formatter, every retry handler, and every test fixture in the codebase.

The failure isn't that you chose the wrong provider. It's that you let someone else's serialization format become your internal architecture. There is a twenty-year-old answer to exactly this problem — Alistair Cockburn's hexagonal architecture, better known as ports and adapters — and agent systems are the most compelling new use case it has had in years.

In 1980, Jon Postel wrote a sentence into the TCP specification that became a founding principle of the internet: "be conservative in what you do, be liberal in what you accept from others." For forty years, engineers have applied it everywhere — parsers that tolerate trailing commas, APIs that coerce "10" into 10, HTML renderers that quietly repair broken markup. The web arguably exists because browsers forgave everyone's mistakes.

Then the caller stopped being a human, and the advice inverted. When an AI agent calls your tool with a stringly-typed number, a mis-nested JSON object, or an enum value that's almost right, the tolerant parser that saves a human developer twenty minutes of debugging does something much worse to the agent: it confirms that the sloppy call was correct. The agent's only training signal inside a loop is the feedback your tool returns. Accept garbage, and you are teaching the model — right now, in this episode — that garbage works.

For a decade, accessibility was the work that slipped. It lived at the bottom of the backlog, resurfaced during compliance audits, and got patched with just enough ARIA to quiet the linter. The economic argument never landed because the affected users were a minority whose churn never showed up in a dashboard anyone was paged about.

Then browser agents arrived, and the economics inverted overnight. Products like ChatGPT's browsing mode, Claude's computer use, and the wave of Playwright-MCP-based automation don't see your pixels. They read the browser's accessibility tree — the same semantic structure screen readers have consumed for twenty years. Every unlabeled button, every div masquerading as a link, every custom dropdown that doesn't expose its state is now invisible not just to blind users but to the agents your business partners are integrating against. A decade of deferred accessibility debt just became integration debt, and integration debt has paying customers attached.

Your team rejected the microservices split in 2024. There was a two-hour meeting, a heated Slack thread, and a spreadsheet comparing operational costs. The conclusion was firm: the monolith stays until the platform team ships multi-region deploys. Everyone who was in the room still remembers.

Your coding agent was not in the room. Last Tuesday it proposed the split again — confidently, with a clean migration plan and a well-argued design doc. The Tuesday before that, a different agent session proposed extracting the billing service. Next week, a third one will suggest replacing your bespoke job queue with the message broker you evaluated and rejected twice. None of them are wrong on the merits as they can see them. They just can't see the merits, because the reasoning that settled these questions lives in a Slack thread that expired, a meeting that wasn't recorded, and the heads of two engineers, one of whom left.

This is the quiet failure mode of agent-assisted engineering: settled questions get re-litigated at machine speed. And the fix is a practice most teams filed under bureaucratic nice-to-haves a decade ago — the architecture decision record.

During the 2025 holiday season, AI agents drove roughly 20% of global e-commerce orders — about $262 billion in sales. That number hides a much stranger fact: almost none of the payment infrastructure those orders flowed through was designed for a non-human buyer. The card networks' entire trust model — the device fingerprint, the IP address, the behavioral biometrics, the "cardholder present" signal — assumes a person is on the other end of the transaction. When an agent checks out, every one of those signals is either missing or synthetic.

The industry's answer is arriving as a delegation layer: cryptographically signed mandates that prove a human authorized a purchase before the software made it. But between the protocol announcements and the operational reality sits a set of unsolved problems that anyone building agentic checkout — or selling through it — needs to understand. The most important one has no answer yet: when the agent buys the wrong thing, who eats the loss?

Your onboarding checklist screens for a lot of things: background checks, conflict-of-interest disclosures, signed IP assignment agreements, a laptop with the right MDM profile. It does not screen for the thing your new senior engineer actually walked in with — a personal AI subscription whose memory contains eighteen months of accumulated context from their previous employer. Architecture debates, incident retrospectives, unreleased product names, the exact shape of the query optimizer they just spent two years building. Not as documents they exfiltrated, but as ambient context an assistant absorbed one conversation at a time, synthesized in the background, and will happily draw on when they ask it a question at their new job.

The same boundary fails in the other direction on the way out. When that engineer leaves you, your offboarding runbook will revoke their SSO, kill their OAuth tokens, and wipe their laptop. It will not — because it cannot — touch the personal ChatGPT or Claude account where your architecture decisions, your incident history, and your roadmap now live as memory entries in a tenant you don't own, can't audit, and can't wipe. Employment has always leaked knowledge through human memory, and the law made peace with that. What's new is a second, machine-grade memory that travels with the person: searchable, persistent, verbatim in places, and invisible to both employers on either side of the transition.

If your agent team coordinates through a shared plan file, a repo, or a design doc that everyone reads and writes, congratulations: you have reinvented the blackboard architecture. It was state of the art in 1975. The uncomfortable part is not the reinvention — good ideas deserve to come back. The uncomfortable part is that the original had three load-bearing components, and most modern agent stacks rebuilt only one of them.

Hearsay-II, the DARPA-funded speech understanding system built at Carnegie Mellon between 1971 and 1976, faced a problem that should sound familiar: many specialized, unreliable experts — acoustic analyzers, syntax predictors, semantic raters — none of which could solve the problem alone, all of which needed to build on each other's partial guesses. The architecture that emerged had a shared workspace (the blackboard), independent specialists (knowledge sources), and a scheduler that decided, at every step, which specialist's contribution was worth executing next. Fifty years later, teams wiring LLM agents together are converging on the same shape — a lead agent, a set of workers, a shared artifact — and hitting failure modes the blackboard literature named and solved before most of us were born.

Your most productive engineer just gave notice. You know the drill: transfer the tickets, document the deploy process, hand off the on-call rotation, schedule the brain-dump sessions. The offboarding checklist has been refined over decades, and it covers everything the company thinks it owns.

Here's what the checklist misses in 2026: that engineer's home directory contains a personal CLAUDE.md tuned over eighteen months, a dozen custom skills that encode exactly how to navigate your gnarliest subsystem, memory files where their agent accumulated hard-won facts about your codebase, and harness settings calibrated through hundreds of sessions of trial and error. None of it lives in the repo. None of it transfers with the account.

On their last day, IT deactivates the laptop, and months of compounded agent configuration — the difference between their agent shipping features unattended and everyone else's agent flailing — evaporates without anyone noticing it existed.

At 4:50 PM on a Friday, someone on the data team kicks off an eval sweep: forty thousand prompts against the company's shared model deployment, scheduled to finish over the weekend. At 5:10 PM, the customer-facing chat assistant starts timing out. The on-call engineer spends two hours staring at dashboards that show the provider returning 429s before someone thinks to ask who else is using the account. Nothing is broken. The system is doing exactly what it was configured to do, which is nothing, because nobody configured it to do anything.

This is the shape of a new class of incident, and it has a property that makes it nastier than an ordinary outage: there is no bug to fix. The eval sweep was legitimate work. The chat assistant's traffic was legitimate work. The failure is that two teams with different urgency profiles were drawing from one undifferentiated pool of inference capacity, and the pool had no opinion about who mattered more. Capacity allocation stopped being an infrastructure detail the moment your company had more than one team shipping against the same provider account — it became a political problem, and the pager inherited it.

The pitch for overnight coding agents is seductive: you go to sleep, the fleet works, and you wake up to finished pull requests. What actually happens is subtler and more expensive. You wake up to a queue — six branches, two failed runs, a dependency bump you didn't ask for, and a refactor that is either brilliant or subtly wrong. The agents did produce code. But the deliverable that landed on your desk isn't code. It's a triage problem, and most teams have no workflow for it.

The numbers say this isn't a niche complaint. A telemetry study of more than 10,000 developers across 1,255 teams found that high-AI-adoption teams merged 98% more pull requests — while review time rose 91% and average PR size grew 154%. Follow-up data from 2026 is worse: production incidents per PR roughly tripled, and 31% more PRs now merge with no human review at all. The bottleneck didn't disappear when agents started working the night shift. It moved to 9 a.m., concentrated into the first ninety minutes of your day, and got a name: the morning review queue.