383 posts tagged with "ai-agents"

Ask an engineer where their company's business logic lives and they'll point at a Git repository. Ask the finance team, the ops team, or the sales team, and the honest answer is a file called pricing_model_v7_FINAL_final.xlsx. The pricing formulas, the headcount plan, the commission calculations, the month-end reconciliation macros — the operational core of most companies runs on Excel and Google Sheets. It has no types, no tests, no code review, and no deploy pipeline. It is production infrastructure maintained like a napkin sketch.

For thirty years this mostly worked, because the only things reading and writing those files were humans — slow, cautious, and equipped with an intuition for "that number looks wrong." That era just ended. MCP servers for Google Sheets and Excel now expose full create-read-update-delete access as first-class agent tools, and every agent platform ships a spreadsheet connector because that's where the customers' data actually is. We have connected the fastest writers ever built to the most fragile production system ever deployed, and most teams did it in an afternoon without a single design review.

The incident channel says the new prompt is hallucinating refund amounts, so you do the obvious thing: repoint the production tag to last week's prompt version. Thirty seconds, no redeploy, textbook rollback. Except the agent gets worse. Last week's prompt references a lookup_order tool that the platform team renamed to orders.search on Tuesday. The memory store is full of preference summaries written by the new prompt's format, which the old prompt reads as user instructions. You didn't roll back the agent. You built a chimera — one-third last week, two-thirds today — and shipped it to production without ever testing that combination.

This is the failure mode nobody's runbook covers: an agent deployment is not an artifact, it's a triple — prompt version, tool contract, accumulated memory state. Rolling back one leg while the other two advance doesn't restore a previous state. It creates a new state that has never existed before, never passed an eval, and belongs to no team's on-call rotation.

Here is a failure you have probably watched happen without naming it. Your orchestrator reads the user's request and briefs a worker agent. The worker runs a dozen tool calls, digests the outputs, and reports back a tidy summary. The orchestrator folds that summary into a brief for the next worker, who does the same. Five hops later, the system delivers a confident final answer — and it violates a constraint the user stated plainly in the second sentence of their request. Nobody dropped the constraint on purpose. Each hop just compressed the context a little, in a direction nobody chose, and the compressions compounded.

This is the telephone game, and multi-agent systems play it constitutively. Every handoff in your pipeline is a lossy compression step: the orchestrator's brief is a paraphrase of the user, the worker's report is a paraphrase of its tool outputs, and the final answer is a paraphrase of paraphrases. The question is not whether information gets lost — it does, measurably — but whether you have decided what is allowed to be lost, or left that decision to the sampling temperature.

Somewhere in your company, an engineer has wired an agent fleet to a SaaS product licensed for fifty human seats. The fleet runs a thousand concurrent sessions overnight, authenticates through one service account, and does the work of a department. Nobody asked legal. Nobody asked the vendor. And if you read the contract carefully, there's a decent chance that entire workload is unlicensed — not because anyone intended to cheat, but because the contract was written for a world where "user" meant a person with a keyboard.

This is the quiet compliance problem of the agent era. Per-seat licensing, terms-of-service automation clauses, fair-use rate limits, and per-user analytics were all designed against a single assumption: usage scales with headcount. Agents break that assumption in every direction at once. A customer running agent fleets doesn't just stress the vendor's pricing model — they often violate the letter of the agreement, the economics behind it, or both.

Somewhere on your laptop right now sits the most detailed record of engineering decision-making your team has ever produced, and nobody has read a word of it. Every agent session — every Claude Code run, every Cursor conversation, every hours-long refactoring saga — gets logged as a transcript. It contains the three approaches that were tried and abandoned, the constraint that forced the ugly workaround, the moment you overruled the model and why. Then the session ends, the PR merges with a one-line commit message, and all of that context goes into a JSONL file that no one will ever open.

We used to lose this information honestly. The reasoning behind a design choice lived in someone's head, decayed over months, and walked out the door when they changed jobs. There was nothing to preserve because nothing was written down. That excuse is gone. The reasoning is now written down, verbatim, timestamped, machine-readable — and we're treating it as disposable exhaust.

If you run coding agents at any real scale, you own a fleet of ephemeral virtual machines. You may not have signed up for that. It happened the moment you decided — correctly — that untrusted, model-generated code should never execute inside your application's trust boundary. Every task gets its own sandbox, every sandbox is a microVM or hardened container, and suddenly the platform team that thought it was building "an agent product" is operating something that looks suspiciously like a miniature AWS Lambda: pool warming, snapshot pipelines, bin-packing schedulers, and a reaper process for the environments nobody came back for.

The trap is assuming your container orchestration instincts transfer cleanly. Some do. But Kubernetes grew up scheduling long-lived, homogeneous services, and agent sandboxes are the opposite: short-lived, wildly heterogeneous, and created at rates that make a deployment rollout look leisurely. The teams that struggle are the ones that treat sandbox infrastructure as "just containers with extra steps." The interesting engineering — and almost all of the cost — lives in four problems: cold starts, filesystem state, packing density, and abandonment.

Your own stack has three environments. Dev is disposable, staging is production-shaped, and prod is sacred. Twenty years of engineering culture — CI gates, canary deploys, blue-green rollouts — all rest on that tiering. Then you give an agent a tool that calls Salesforce, QuickBooks, or Gmail, and the tiering silently evaporates. There is no staging Salesforce for your customer's org. There is no shadow copy of the invoice ledger. The moment a tool call crosses your network boundary into a third-party SaaS, there is exactly one environment, and it is production.

This is the least discussed gap in agent engineering. We have gotten good at sandboxing the agent's compute — containers, egress allowlists, resource caps. We have gotten passable at evaluating the agent's reasoning — offline evals, LLM-as-judge, trajectory scoring. But the agent's actions on the outside world still run against live systems holding real customer data, because for most SaaS surfaces nothing else exists. Teams quietly resolve this the only two ways they can: test against production, or don't test at all.

You are halfway through renaming a function when the file reloads under your cursor. The diff you were staging no longer matches the working tree. Your dev server hot-reloads twice for no reason you can see, and a test that passed ten minutes ago now fails in a file you never opened. Nothing crashed. Nothing warned you. You and your coding agent have just been editing the same working tree at the same time, and you found out the way most teams find out: through mystery diffs.

Databases solved this problem fifty years ago and gave it a name — concurrency control. Two writers touching shared mutable state need either a lock, an isolation boundary, or a merge protocol, and the choice among those is a design decision with known trade-offs. Yet most engineering teams adopting coding agents never make that decision explicitly. They drop a second writer into a single working tree, keep the habits of a single-writer world, and then file the resulting weirdness under "AI being flaky." It is not flakiness. It is a race condition, and you are one of the racers.

Somewhere in your support queue this quarter, a conversation happened with no humans in it. Your customer's procurement agent opened a ticket about an invoice discrepancy, your support agent answered with the refund policy, and the two of them went back and forth eleven times before the thread died — unresolved, unescalated, and invisible to both companies until the customer's CFO asked why the credit never arrived. Neither bot did anything wrong by its own rules. That's the problem.

Everything we've built for AI customer support assumes a human on the other end. Sentiment detection, frustration thresholds, "would you like to speak to a person?" — all of it models a customer who gets tired, gets angry, or gives up. A customer's agent does none of those things. It is infinitely patient, procedurally polite, and relentlessly on-script. When it meets your equally patient, equally on-script support agent, you don't get a resolution or a complaint. You get a stalemate that looks, in every dashboard, like a healthy conversation.

Every progress bar you have ever shipped rests on one assumption: you know the denominator. Uploading a 40 MB file? The denominator is 40 MB. Installing 212 packages? The denominator is 212. The bar is honest because the total work is known before the work begins.

An agent breaks this assumption at the root. It doesn't execute a predetermined list of steps — it discovers its remaining work as it goes. It reads a file, which reveals three more files worth reading. It runs the tests, which fail, which spawns a debugging detour nobody planned. Step 4 of 7 becomes step 4 of 19 becomes, occasionally, step 4 of 4 because the last three turned out to be unnecessary. Percent-complete for an agent isn't hard to compute. It's undefined. There is no denominator until the work is finished, at which point the answer is always 100%.

Yet look at what we ship: spinners that promise imminent completion, bars that creep to 90% and stall, labels that say "almost done…" on minute two of a task that takes eight. These are all small lies, and users catch them. The interesting design question isn't how to fake progress more convincingly — it's what honest reassurance looks like when the duration of the work is structurally unknowable.

Fifteen years ago, we learned to fear the N+1 query: an ORM that looked innocent in code review would fire one query for a list and then one more query per row, and a page that should have made two database calls made two hundred. We fixed it with eager loading, batching, and a generation of linters. Then we built AI agents, and we shipped the same bug at a much more expensive layer.

A single agent task — "reconcile these invoices," "triage this incident" — routinely makes dozens of serial tool calls. Each one is a full network round trip: agent to tool, tool to data store, data back through the tool, result serialized into the model's context, another inference pass to decide the next call. If your inference runs in one cloud and your data lives in another, every one of those hops crosses a metered, high-latency boundary. The dominant cost term of your agent system is no longer the model. It's the geography.

Nobody itemized this. Latency budgets were written per call, egress was a rounding error on the storage bill, and the model invoice got all the scrutiny. Meanwhile the tool loop quietly became the chattiest client your infrastructure has ever served.

You built an agent that checks supplier prices every morning. It runs a real browser, clicks real buttons, and does exactly what a diligent employee would do — just faster and at 6 a.m. Then one day it stops working. No error in your code. The supplier's site now returns a challenge page, then a 403, then nothing at all. Your agent didn't break. It got classified.

Here is the uncomfortable symmetry every agent builder eventually confronts: the web's defenses were tuned by a decade of scraper wars, credential-stuffing attacks, and inventory-hoarding bots — and your legitimate agent is statistically indistinguishable from all of them. Automated traffic passed 50% of all web traffic in 2024, and roughly 37% of the total is classified as malicious. The immune system that evolved to fight that flood does not care about your intentions. It cares about your fingerprint, and your fingerprint says "bot."