Artificial Intelligence
Why AI Agents Need a Runtime, Not Another Framework
Ran Aroussi argues that AI teams keep rebuilding the same plumbing, and that agents should be declared and run like any other piece of infrastructure.
What needs to be done in AI: A conversation with Ran Aroussi
Video from Bas Steins.
Generated from the canonical interview transcript and validated against source data by Guests on Air.
Why do AI agents need shared infrastructure instead of custom frameworks?
Because most AI projects rebuild the same parts: memory, observability, tool calls and domain knowledge. Ran Aroussi says that work is nearly identical from one team to the next, so it belongs in a shared runtime. Agents should be declared in configuration and run as native parts of the system, which leaves teams free to spend their effort on their users.
Ran Aroussi has spent years helping companies scale software that buckled under sudden growth, from ad networks serving three to four billion ads a day to startups that hire his team as a technical partner. In a conversation with Bas Steins, he turned that experience toward artificial intelligence and asked why every team still builds its own foundations.
His answer is blunt. Building an AI product today feels like writing a new web server for every hello world page. Teams stitch together memory, observability, domain knowledge and tool calls by hand, even though that work is almost identical from one company to the next. The problem, as he sees it, is not a lack of knowledge but endless duplication.
This article looks at the case he makes for treating agents as infrastructure: why a declarative runtime beats yet another framework, why autonomy matters more than rigid workflows, and why the lessons of the early web still apply. It is a practical view from an engineer who says he reviews and tests every line of code his tools produce.
Key takeaways
- Most AI teams rebuild the same memory, observability and tool plumbing before they reach the part customers see.
- Agents should be declared in configuration and run by a shared runtime, not tied to one programming language.
- Standard operating procedures guide an agent while leaving it room to replan when a step fails, unlike rigid workflows.
- The web already solved logging, scaling and observability, so AI infrastructure can borrow those answers.
1. Everyone is building the same thing
Aroussi compares the current state of AI development to the early web, when developers printed pages from Perl scripts line by line. Today nobody writes a web server to publish a simple site. Yet teams building AI products still assemble their own memory layers, observability tools, domain knowledge stores and tool calls before they can start on anything a customer would notice.
He summed the situation up with a post he had shared before the conversation. Everyone knows what needs to be built, and the trouble is that everyone is building it separately, across agent frameworks in different languages and a steady stream of workflow interfaces. Each team pays the same cost, and none of them gets that time back for their own product.
His response is to treat the whole system as something you deploy rather than something you code from scratch. He describes a complete AI system, with agents, tools, memory, triggers, webhooks and chat interfaces, packaged into deployable units and defined in configuration files, much as engineers already configure a web server or a container.
2. Agents as native primitives
The core of his argument is that an agent should not belong to a programming language. Business logic can live in whatever language suits a team, but the agent itself is declarative. An agent needs a runtime that treats it as a native part of the system, rather than a library bolted onto an application and rewritten for every stack.
That shifts where the real engineering happens. Aroussi expects most custom work to move into the tools an agent calls, often written as MCP servers. The agent can be little more than a markdown or YAML file that describes its role, while the tools do the execution. He points to how quickly assistants gained skills and custom agents without any coding.
He also sees MCP as the tool standard that will last. It is not the most efficient protocol, he says, but it works, it is familiar, and it can run over the web or locally like a command line tool. Because the major AI companies have adopted it, he expects gradual changes to MCP rather than a rival protocol replacing it.
3. Autonomy over workflows
Aroussi calls the phrase agentic workflow a contradiction. A workflow is a predefined set of steps, while an agent is supposed to have autonomy. If step one fails in a workflow, the whole operation stops. He wants an agent that notices the failure, plans again, and takes a different route to reach the same goal.
His alternative is standard operating procedures. An SOP tells the agent how the team usually does something, and the agent adapts that guidance to the conditions in front of it. The same thinking shapes his view of memory, which he splits into domain knowledge, user memory, episodic memory, buffer memory and working memory, each kept separate for every user.
None of this means chasing the newest architecture. The engineer who prefers a well structured monolith to microservices adopted for their own sake applies the same test to AI. Use what serves the purpose, avoid tools that lock you into one vendor, and lean on the standards that already work, so the effort goes into what makes the product different.
