Context-Oriented Software Development

Almost every conversation about AI agents right now is about the same three things: prompts, models, and reasoning. Which prompt, which model, how many reasoning steps. It's a productive conversation, and it's aimed at the wrong layer.

For decades, software has been built on a single assumption: code is the primary unit of execution. Developers write instructions, the machine runs them, and state is a supporting concern — parked in a database, a file, a variable — off to the side of the real action. Monolith or microservice, on a mainframe or in the cloud, the architecture stayed code-oriented underneath.

Machine learning bent that assumption. Large language models bent it further. Andrej Karpathy's name for the latest bend is Software 3.0 — a world where behavior is increasingly authored in natural language, prompts become programs, and the model is the interpreter. It's a good description of how intelligent systems get written.

It says almost nothing about how they should run.

That gap is the whole subject of this piece. Because a different pattern is emerging underneath the prompt talk — one where the primary unit of execution is neither code, nor a model, nor a conversation, but context. I'll call it what it is: Context-Oriented Software Development (COSD).

Context-Oriented Software Development is an architectural paradigm in which context becomes the primary unit of execution. Instead of centering software on code, workflows, or conversations, a COSD system operates on persistent, evolving context that is continuously interpreted, enriched, and acted upon by intelligent processes.

And the reason this belongs on this blog, rather than in a general essay about the industry, is that COSD isn't a thing you'd go and build. It's the shape FloMorphic already draws. Every claim below has a concrete answer on a runtime you can already run.

The evolution of software, in one axis

The history of software reads as a progression of what, exactly, you execute.

Software 1.0 executes code.

Input → Code → Output

Behavior is written by hand, deterministic, and explicit. This is most of the software that has ever existed.

Software 2.0 executes models.

Input → Model → Output

Instead of writing the behavior, you train it. Logic stops being handcrafted and starts being learned from data.

Software 3.0 executes prompts.

Prompt → LLM → Response

Behavior gets authored in human language and interpreted by a large model. Powerful — and, as usually practiced, stuck at the level of a single reasoning cycle.

Every one of these is about how behavior is expressed. None of them answers the question that actually decides whether an intelligent system survives contact with a real business:

What is the execution model for a system that has to think continuously, over time?

The ceiling of prompt-oriented systems

Look closely at almost any AI system in production today and you find the same loop: it receives context, reasons, produces an answer, and terminates.

Request → Prompt → LLM → Response

Even most "agent frameworks" live inside this shape. They add memory, tools, a planner — but the execution model is still a chain of individual reasoning cycles bolted together, and the moment the process needs to outlive a single cycle, the framework is improvising.

The trouble is that real work doesn't fit inside one cycle. Real intelligent processes have to:

• run for days or weeks, not seconds
• pause to collaborate with a human and resume where they left off
• wait on an external event that hasn't happened yet
• survive a crash without losing their place
• fan out across distributed infrastructure
• hold continuity across all of it

None of these is exotic. They're the default conditions of a business process. Which means the real challenge was never "make the agent smarter." It's make the intelligent process durable. That's the same reframe Stop Chatting, Start Working makes about agents that pause for people, and the same one Reason Once, Reuse Many Times makes about reasoning you keep instead of discard. Intelligence you can't sustain isn't infrastructure. It's a demo.

Context as the unit of execution

COSD starts by refusing the premise that context is an input.

In a prompt-oriented system, context is the stuff you assemble and hand to the model before it thinks. In a context-oriented system, context is what's executing. It's not fed to the process — it is the process.

Picture a persistent context object partway through a real case:

{
  "customer": { "id": 12345, "tier": "gold" },
  "case": { "status": "under_review" },
  "history": [ "...", "..." ]
}

This object isn't a payload passed between functions. It lives, and it evolves across the entire lifecycle of the work. Every action enriches it. Every decision reads it. Every participant — model or human — contributes to it. The process is no longer a sequence of instructions; it's the continuous evolution of this one thing.

Context → Decision → Updated Context → Decision → Updated Context → …

On FloMorphic this is not an aspiration you architect toward — it's the base fact of the runtime. The run's context is a single live document the flow reads and mutates; nodes don't pass arguments to each other so much as they read from and write to that shared, persisted state. The "context object" above isn't a design pattern you'd assemble. It's just what a run is.

Intelligence as routing, not response

Here's where COSD parts ways hardest with the prompt-first world, and it's the part that keeps these systems governable.

Classic software routes with explicit rules:

if amount > 1000: review
else: approve

Readable, auditable, and blind — it can't tell a routine $1,001 refund from a fraud pattern. A prompt-first system fixes the blindness by handing the whole decision to a model and hoping the output is sane. COSD takes a third position: let the model interpret, but only choose among paths the designer drew.

Analyze the request in context. Choose one:
- Approve
- Reject
- Escalate

The available exits stay governed by the people who built the system. The model's only job is to decide which predefined path best fits the current context. That's the balance the whole architecture rests on: semantic judgment, inside a corridor you can see. On FloMorphic this is not a special capability — it's tag-on-transition routing, the same mechanism every flow already uses to decide where to go next. Intelligence stops being a source of arbitrary output and becomes a routing decision on a visible graph — observable, auditable, and predictable, without giving up the reasoning that made it worth using a model at all.

Hierarchical intelligence through composition

As these systems grow, complexity is the enemy — and the answer is the oldest one in software engineering: composition. A process invokes another process.

Main Process
  → Research Process
  → Analysis Process
  → Execution Process

Each sub-process owns a bounded responsibility and can be reasoned about, tested, and reused on its own. It's function composition, aimed at intelligent work instead of pure code — reusable units of intelligence that combine into larger ones.

And, again, on FloMorphic this isn't a feature to build. Multi-agent orchestration is a composition: one graph fans out to sub-graphs that run in genuine parallel, a barrier waits for every branch, and their results merge back into shared context. A supervisor coordinating three specialists is exactly that shape — drawn, not coded, and traceable back to the nodes that produced each part.

Durable execution is the whole game

If there's one property that separates COSD from everything before it, it's durability.

A prompt-oriented interaction is transient by nature: it lives for one request and vanishes. A context-oriented process can pause for hours, days, or weeks and preserve its complete state across the gap.

Day 1:  Review Request → Wait For Approval → [state persisted]
Day 5:  [state restored] → Continue Execution

When it resumes, it isn't restarting. It holds everything it had — context, execution position, the path it took to get here, its pending actions, its full state. Continuity stops being a custom-engineered miracle and becomes a built-in property of the platform.

This is the mechanism underneath two things this blog has already argued from other angles. Resumption is an execution primitive on FloMorphic — a run can park, persist its entire state, and continue later on the exact context it held. That single capability is what lets a flow wait three days on a human and resume as if no time had passed, and it's the same durability that lets you snapshot a frontier model's reasoning and restore it into a later run like a VM's RAM image. Pausing for a person, and freezing reasoning for reuse, are the same move — because the context is a durable, portable, restorable object rather than variables trapped inside a function call.

The future of AI may depend less on making models smarter than on making intelligent processes reliable. That's a runtime problem, not a prompt problem.

Distributed runtimes for intelligent processes

Every computational revolution eventually demanded its own runtime. The web needed web servers. The cloud needed orchestration. Containers needed Kubernetes. A new unit of execution always ends up needing infrastructure built specifically to manage it.

Context-oriented software is no different. Once intelligent processes are long-lived, first-class things, they need a runtime that treats them as such — one that provides state persistence, fault recovery, event handling, distributed execution, scale, and observability. Without that layer, "intelligent systems" stay demos: impressive in a notebook, unsurvivable in production.

This is the layer FloMorphic is, and the reason the rest of this blog keeps returning to the same runtime from different doors — the Company Brain, reasoning reuse, plugins that extend it like a browser extension. They're all the same underlying claim: the interesting engineering has moved from the model to the runtime around it.

Context is the process

The deepest shift COSD asks for is philosophical, and it's worth stating plainly.

Traditional software treats context as supporting information. Agent systems treat context as memory — something the process has. Context-oriented software treats context as the process itself. The state isn't stored beside the execution; execution is the continuous interpretation and evolution of that state.

That reframes the design question. You stop asking:

What should the software do?

and start asking:

How should the context evolve?

Which happens to be how organizations actually work. A business isn't a set of functions. It's a set of evolving contexts — a claim, an onboarding, a deal, a case — moving through decisions and events over time. COSD models the business as it is, not as a call stack pretending to be one.

Conclusion

Software architecture has always tracked the dominant computational paradigm of its era. Code-oriented systems defined the first generation. Model-oriented systems the second. Prompt-oriented systems are defining the third.

The next step is context-oriented systems — where context becomes the primary execution artifact, intelligent components become interpreters of context rather than isolated reasoning engines, and a durable runtime carries continuity across time, infrastructure, and organizational boundaries.

Whether "COSD" becomes a term anyone else uses is beside the point. What's clear is that the future of intelligent systems needs more than better prompts, bigger models, and cleverer agents. It needs an architecture that can sustain intelligence as a continuous process — and in that architecture, context becomes the most important software primitive of all.

You don't install that architecture. You draw it.

Repo: github.com/FloMorphic/getting-started

Concepts and docs: inflowenger.com/flomorphic

New here? The foundation this rests on is The Model Proposes, the Graph Decides, and the durability it leans on shows up again in Stop Chatting, Start Working and Reason Once, Reuse Many Times.