Most agent workflows still begin as a pile of instructions.
There is the system prompt. There is an AGENTS.md file. There are coding rules copied from another repo. There are notes about how to run tests, which branches matter, how deployments work, which files are generated, and what the team considers acceptable behavior. There are MCP server definitions, local tool configs, environment variables, access tokens, project docs, issue trackers, Slack context, and a few hard-won reminders that only exist in someone's prompt history.
This is understandable. Agents became useful before the infrastructure around them became mature. The fastest way to make an agent better was to add another instruction, another file, another rule, or another tool. Over time, the workflow improved. It also became difficult to reproduce.
The result is prompt scaffolding: a manually assembled support structure around each agent session. It works, but it is fragile. Every new project asks the same questions again. What should the agent know? Which tools may it use? What standards should it enforce? Which context is trusted? Which operational habits should follow it from one workspace to the next?
The next useful shift is from session-defined agent behavior to infrastructure-defined agent behavior.
The Problem With Session-Defined Behavior
A session is a poor place to define durable behavior.
It is too small, too temporary, and too dependent on the person starting it. A careful engineer may provide a strong prompt, attach the right files, expose the right tools, and explain the team's standards. Another engineer may omit half of that setup. A CI agent may receive a different version. A local coding agent may have access to one MCP server while a cloud runner has another. The behavior looks similar at the surface, but the operating conditions are different.
This is where many agent failures come from. The model is not always missing intelligence. It is often missing the runtime conditions that make the desired behavior possible.
A prompt can say, "follow our release process." That does not mean the agent has the release process, the repository permissions, the changelog format, the deployment environment, the right issue tracker, or the ability to verify the result. A prompt can say, "use the project's conventions." That does not mean the conventions are loaded, current, or expressed in a form the agent can apply consistently.
The gap is not just context. It is operational context: rules, tools, credentials, resources, policies, and environment-specific assumptions that determine what an agent can actually do.
From Instructions To Runtime Objects
A more durable model treats these pieces as reusable runtime objects rather than one-off prompt fragments.
A Runtime Object is not just a paragraph of instruction. It is a packaged unit of agent operating behavior. It can include standards, context sources, tool access, authentication requirements, execution limits, expected outputs, and verification habits. It can describe how an agent should review code, prepare a migration, triage an issue, generate a release note, or operate inside a specific engineering environment.
The important change is that the behavior becomes addressable and reusable. It does not need to be reconstructed from memory each time. It can be versioned. It can be composed. It can be applied across projects without copying a prompt into another text box and hoping the surrounding environment matches.
This matters because useful agent behavior is rarely a single instruction. It is a small operating system around the model.
A code review agent, for example, needs more than "review this PR." It needs repository access, diff access, project standards, test expectations, severity language, comment style, knowledge of generated files, awareness of deployment risk, and a rule for when to approve versus when to request changes. If those pieces live in scattered notes, behavior will drift. If they live as a runtime object, the workflow becomes easier to carry and improve.
Runtime Stacks
Once behavior is represented as reusable objects, those objects can be composed into Runtime Stacks.
A Runtime Stack is the agent's operating environment for a class of work. One stack might support day-to-day coding inside a product repo. Another might support infrastructure changes. Another might support support engineering, where the agent needs customer context, issue history, logs, and stricter handling of sensitive data. Another might be designed for documentation work, with access to source files, published docs, and style standards.
The stack defines what the agent should know, what it can reach, and how it should behave. The session becomes less responsible for assembling the workflow. The infrastructure carries the workflow.
This does not remove prompting. It changes the role of prompting. The prompt becomes the task request, not the entire operating manual. Instead of packing every rule and tool description into the session, the user can ask for work inside a known runtime with known behavior.
That is a cleaner separation of concerns. The task belongs in the prompt. The operating environment belongs in infrastructure.
Why MCP Matters
MCP is useful here because it gives agent systems a common way to expose tools and context. But tool exposure alone is not the full story.
A list of MCP tools tells an agent what it can call. It does not necessarily define why those tools exist, when to use them, how to combine them, which context is authoritative, or what standards should govern the result. That higher-level structure is where Runtime Objects and Runtime Stacks become important.
The practical direction is MCP-compatible infrastructure that can expose not just raw tools, but composed operating environments. An agent should be able to enter a runtime where the relevant tool access, authenticated context, and behavioral standards are already present. The interface can remain compatible with agent protocols, while the operational model becomes more durable than a tool list.
This is the difference between giving an agent a socket wrench and giving it a maintained workshop with labeled tools, access rules, safety constraints, and a clear job order.
FlowState As An Example
[FlowState](https://offband.dev/apps/flowstate) points in this direction by treating agent setup as something that can be composed and reused rather than hand-built for every session.
The useful idea is not that every team needs a particular product shape. It is that agent workflows need a runtime layer. Teams already have operational standards. They already have privileged context. They already have tools that need authentication. They already have repeated workflows that should behave consistently across machines, repos, and environments.
FlowState is a practical example of making those pieces explicit: reusable objects, composed stacks, and addressable infrastructure that an agent can run against. The value is not in adding more instructions to a prompt. The value is in moving repeatable behavior into a place where it can be managed like infrastructure.
That framing also makes the tradeoffs clearer. If an agent needs access to production logs, that should be part of an explicit runtime with permissions and boundaries. If an agent should follow a release process, that process should be represented as a reusable operational standard. If an agent should behave differently in a regulated environment than in a prototype repo, that difference should be encoded in the stack, not left to whoever starts the session.
What Builders Should Standardize
The immediate work for builders is not to invent elaborate agent platforms. It is to identify the parts of agent setup that are already being repeated manually.
Start with the rules that keep getting copied between projects. Then look at the tools that require the same explanation every time. Then look at the context sources that are treated as authoritative but are not automatically available. Then look at the workflows where agent behavior needs to be consistent because the cost of drift is high: code review, release work, incident response, migrations, security-sensitive changes, customer support, and production operations.
Those are the candidates for runtime infrastructure.
A useful Runtime Object should answer a few concrete questions. What behavior does it provide? Which tools or context does it require? What permissions does it assume? What outputs should it produce? How should success be verified? What should the agent avoid doing?
A useful Runtime Stack should make those objects available in a coherent environment. It should reduce setup time, but more importantly, it should reduce behavioral variance. The same workflow should not depend on whether someone remembered to paste the right instruction block into the chat window.
Durable Agent Workflows
Prompt scaffolding was the right early move. It let teams discover what agents needed in order to be useful. But scaffolding is not the same as infrastructure.
As agents move from experiments into daily engineering work, the limiting factor becomes less about writing the perfect prompt and more about providing a stable runtime. The agent needs the right tools, the right context, the right permissions, and the right standards before the task begins.
That is the real transition: from asking every session to define the operating model, to giving agents reusable infrastructure that already knows how work should happen.
The teams that make this shift will spend less time recreating setup and more time improving the systems around their agents. Their workflows will be easier to audit, easier to move between projects, and easier to trust under real operational pressure.
The prompt will still matter. It just should not have to carry the whole runtime on its back.