Konstantin Semenenko
July 8, 2026
5
minutes read
The internet was built for people. Mobile was built for people. This wave is being built for machines, agents that read, decide, spend, and act on their own, and they need a different stack than humans do. The categories emerging: spend controls, trustworthy memory, safe sandboxes, identity and permissions, reliable always-on runtime, and observability that answers "why did my agent do that." Most of it barely exists yet. For anyone building infrastructure, this is as early as it gets, and the teams building for agents now are building the plumbing of the next decade.
The most useful lens on AI right now is that we are building software for a new kind of user, and that user is not a person. Agents read instead of clicking, decide instead of waiting, spend real money, and act on external systems on their own. Software built for humans assumes a human in the loop, watching, clicking, catching mistakes. Agents remove that assumption, which means an entire infrastructure layer has to be rebuilt for a user that behaves nothing like a person. The categories are already visible: spend controls, trustworthy memory, safe sandboxes, identity and permissions, reliable runtime, and deep observability. Most are barely built. This is a map of the agent-native stack, and where the real opportunities sit.
We build agent systems and the infrastructure under them, so this is a practitioner's view, grounded in what we have already had to build ourselves, not a prediction deck.
The internet and mobile were both built around a human: a person who reads a screen, clicks deliberately, hesitates, and notices when something is wrong. Every layer, from UI to billing to permissions, assumes that person is present. An agent breaks all of it. It does not read a screen, it reads your docs. It does not hesitate, it can spend $100 in tokens in eight minutes on a bad loop. It does not notice it is being manipulated, and it acts at machine speed with real credentials.
So "add AI to the product" is not the frontier. The frontier is the infrastructure a machine user needs that a human user never did, and it is a genuinely new category of software because the assumptions underneath the old stack no longer hold. Below are the layers that have to exist, several of which we have already had to build to run agents safely.
The first thing you learn running agents at scale is that they burn money in ways no human would. A person hits a task and moves on; an agent hits a loop and spends a fortune before anyone notices. We know this precisely, because a single run of ours billed $303,030 in 29 days, and the biggest lever on that number was not the model, it was the architecture around it: routing, caching, and bounded retries.
That is a whole category: spend controls built for agents, budgets, caps, per-task limits, and real-time attribution, so a runaway loop is a contained incident, not a surprise invoice. Humans get expense policies; agents need the machine equivalent, enforced in code. It is the FinOps layer for a user that can spend faster than any person, and we wrote the playbook for it in AI token cost optimization.
Agents are only as good as what they remember, and most agent memory today is a chat history that evaporates or drifts. The infrastructure opportunity is memory an agent can trust: a durable, shared store it reads from and writes to, consistent across sessions and across agents. Whoever becomes the reliable shared brain that agents build on becomes infrastructure, in the way a database or an identity provider is infrastructure.
This is not hypothetical for us. Reliable retrieval is exactly why we built an open-source graph-based RAG library in C# that links documents through their entity relationships, so an agent finds the fact that lives in a separate document instead of relying on keyword overlap. Memory an agent can trust is the difference between an agent that compounds knowledge and one that starts from zero every run.
You would not give an autonomous agent your live payment credentials and root access and hope. You give it a sandbox, a bounded environment where it can act, fail, and be observed without touching anything that matters. Safe execution environments for agents are a category almost nobody has built deliberately, and every serious agent deployment needs one.
The principle is data and blast-radius isolation: the agent operates on a sanitized, permissioned view, and the real systems sit behind a boundary the agent cannot cross without explicit authorization. This is the same discipline we apply for regulated workloads in private AI for regulated teams, and it maintains an open-source anonymization library for exactly the sanitized-view problem. A sandbox is not a nice-to-have for agents; it is the thing standing between a bad decision and a real one.
When an agent acts, a hard question appears: on whose behalf, and with what authority? An agent needs to prove it is acting for a real person and is authorized to spend or commit on their behalf, and no human is there to click "approve." That is a permission layer that does not really exist yet: machine identity, delegated authority, scoped and revocable permissions, and a clean boundary between what the agent may propose and what it may execute.
This is deep infrastructure, and it connects to real liability: when an agent commits on your behalf, someone is accountable for the result. The teams that build the identity-and-authority layer, who the agent is, what it is allowed to do, and how that authority is proved and bounded, are building something as fundamental for the machine era as OAuth was for the human web.
An agent that runs intermittently is not much use; the value shows up when it runs continuously, watching, reacting, completing multi-step work over time. That means an agent needs a reliable place to live, an always-on runtime that stays up, handles failure, and sustains throughput without the whole workflow dying when it hits a limit. A human hits a rate limit and shrugs; an agent hits one and the workflow collapses.
Reliable, high-throughput agent runtime is its own business, and it is squarely where our stack already lives. We run agents on Microsoft Orleans, including an open-source local agent orchestrator, dotPilot, one control plane for multiple agents with a fleet board and per-action tracing, plus Orleans-native rate-limiting and state-transition libraries built because uncontrolled transitions caused cascading failures in production. The always-on box an agent lives on, resilient, observable, throttled, is infrastructure the machine era will pay for.
Agents fail silently and strangely. A human error usually announces itself; an agent returns a confident, well-formatted answer that is wrong, with nothing logged. So one of the most valuable things to build is the replay, the ability to reconstruct exactly what an agent did and why, step by step, and diagnose where it went wrong.
This is not optional at scale, and it is why we treat step-level tracing as core, the subject of our piece on AI agent observability, and why dotPilot ships with OpenTelemetry tracing for every agent action, tool call, and workflow step. "Why did my agent do that" is going to be one of the most valuable questions in software, and the infrastructure that answers it cleanly will be worth a great deal.
Push these trends out and the categories get stranger, and worth naming even while speculative. Agents will transact with other agents, which means reputation you can check before you trust one, escrow that releases only when a job is verifiably done, and dispute resolution when an agent does the work badly. Agents will subscribe to specialist agents, recurring revenue machine to machine. And eventually the physical world arrives: a warehouse robot paying for its own compute, a marketplace where software agents post real-world jobs machines pick up. These are early and unproven, so treat them as direction, not roadmap. But the direction is clear: money, identity, and trust rebuilt for participants that are not human.
The internet was built for people, mobile was built for people, and this wave is being built for machines. Agents need a stack humans never did: spend controls for a user that can burn money in minutes, memory it can trust, safe sandboxes, machine identity and delegated authority, always-on reliable runtime, and observability that explains its own behavior. Most of it barely exists, and the teams building it now are laying the plumbing of the next decade. We are building parts of it already, out of necessity, and that is usually the sign a real infrastructure category is forming.
If you are building agent systems and need the infrastructure under them, spend control, safe execution, reliable runtime, and real observability, built by a team that has already had to solve it, that is where our AI Dev Team work starts.
What infrastructure do AI agents need? A stack built for a non-human user: spend controls (budgets and caps for a user that can burn money fast), trustworthy shared memory, safe sandboxes for action, machine identity and delegated authority, reliable always-on runtime, and step-level observability. Most of these barely exist as mature products yet.
Why can't agents use the same infrastructure as human software? Because human software assumes a person in the loop, watching, clicking, catching mistakes. Agents read instead of click, spend on their own, act at machine speed, and fail silently. Every layer that assumed a human, billing, permissions, review, has to be rebuilt for a machine user.
What is the biggest infrastructure gap for AI agents today? Several are early, but spend controls, safe sandboxes, and machine identity/authority are the most pressing, agents burn money in runaway loops, act with real credentials, and commit on a person's behalf, all without a human gate. These are the layers most missing from today's stack.
Why do AI agents need spend controls? Because they burn money in ways no human would, a single bad loop can spend a large sum in minutes. Agent spend controls, budgets, per-task caps, and real-time attribution enforced in code, turn a runaway loop into a contained incident instead of a surprise invoice.
Is building for AI agents a real opportunity? The categories, spend control, memory, sandboxes, identity, runtime, observability, are genuinely new because agents behave nothing like human users, and most of the stack is unbuilt. It is early and partly speculative, but the underlying need, infrastructure for a machine user, is real and already showing up in production.
