The Growing Medium for API Ecosystems
Why shared state matters more than ever
We talk a lot about how statelessness in service design (a key principle in RESTful systems) that helps services stay scalable and simple. But the more stateless your services are, the more your system needs somewhere to remember and that place is called "shared state."
Composable systems continue to be a hot topic, especially now that LLMs are gaining traction as API clients. In response to this latest ground-swell of interest, we're all being encouraged to build smaller, task-focused services. We're assembling workflows from modular “jobs” or orchestration scripts. And we’re setting ourselves up to let autonomous agents like LLMs and planners decide what to do next.
But all this flexibility comes with a tradeoff: the more loosely coupled your individual parts, the more your overall system depends on something to hold them together. Something that can preserve continuity, enable cooperation, and reflect progress.
That something is shared state.
This notion of sharing state (whether at the service, session, or system level) is not new. But it is essential. Shared state is the glue between services, the soil they grow in, and the memory that makes orchestration and planning possible.
In the sections that follow, we’ll look at shared state as a growing medium for modular services, explore the balance between stateless services and stateful systems, and examine how shared state supports both human orchestration and agentic planning.
If we want systems that evolve and adapt, we need to start with systems that remember.
Shared State Is the Growing Medium
Shared state is like soil and your services are like seeds.
Seed that are stateless, self-contained, and ready to do useful work. But seeds don’t grow in midair. They need something to connect them. Something to hold moisture, pass nutrients, and support roots.
That’s what shared state does for composable systems. It gives services a place to leave traces. It holds results long enough for others to pick them up. It lets one service’s output become another’s input—without tight coupling or hidden contracts.
This works because of a simple principle: services don’t need to know who will use their results. They just need to leave the results in a place where other services can find it.
Services don’t need to know who will use their results. They just need to leave the results in a place where other services can find it.
That’s what makes composability possible. Not brittle pipelines. Not hardwired logic. A shared workspace where each part contributes to a bigger whole.
Picture this: a geolocation service stores coordinates. A weather service picks them up and adds a forecast. A formatter turns it all into a readable report. None of them know about each other. But through shared state, they collaborate.
Stateless services stay focused on their task and the system does the work of remembering for them.
When you don’t have shared state, you have to hardcod assumptions. You pass data around in awkward ways. You end up creating an endless number of unique interface signatures and shapes. And, along the way, you lose the flexibility that composability promises.
But when your architecture is grounded in the foundation fo shared state, services stay can light and the system stays smart.
Stateless Services, Stateful Solutions
Each service you write should be stateless. That’s a good rule of thumb.
Stateless services are easier to build, easier to test, and easier to scale. They don’t carry history. They don’t track progress. They take an input, produce an output, and move on. Clean and self-contained.
But when you start composing services into a solution by bringing multiple pieces together to solve a problem you need memory. You need to know what’s already happened. What still needs to happen. What’s in flight and what’s finished.
That’s where shared state comes in.
Instead of pushing memory into the services themselves where it creates coupling and complexity, you lift it out into a dedicated space. Now each service can stay stateless, while the system becomes stateful.
This separation is powerful. Services stay modular. State stays inspectable. And solutions become things you can design, debug, and evolve.
Whether you’re orchestrating tasks by hand or handing them off to an agent, shared state gives you a place to track what the system is doing—step by step, decision by decision.
The parts remain stateless. But the whole behaves like it knows what it's doing.
Humans Orchestrate, Agents Plan. Both Need Shared State.
In the old days, orchestration meant writing a script. You wired services together by hand, spelled out each call, passed values explicitly.
But that’s changing. Now, we have agents, LLMs, and Planners. We’re seeing the rise of systems that improvise instead of follow instructions. And for those systems to work, they need context.
LLMs don’t generate magic. They generate in context. The more they can see, the better they perform. That’s true in chat. It’s true in orchestration.
In composable systems, shared state is the context. It’s the memory of what came before. The space where values accumulate. The environment where reasoning happens.
For a human planner, shared state shows you what’s done. It lets you base the next step on the last one. It’s a kind of job history. For an AI, shared state is the world it sees. It’s how it decides what to do next. Whether for Humans and machines, shared state can help answer questions like: “What’s already complete?” “What data is available?” “What tool fits the current need?”
Shared state creates an environment where both humans and machines can reason in real time without rewriting everything. It’s the connective thread that gives structure to the system’s behavior.
If we want services to be agent-ready, we have to give agents a place to think.
Shared state is that place.
Final Thought
I wrote extensivlely about shared state in RESTful Web API Patterns and Practices Cookbook. There, it was about coordinating long-running workflows. Making sure distributed steps could line up over time. That’s still true. But now we’re asking more from our systems.
Today, shared state is the growing medium for composability. It’s what makes service boundaries safe instead of brittle. It’s what lets machines coordinate without us. It’s what turns stateless parts into a system that can adapt.
So the next time you’re designing a system, don’t just ask what each service does. Ask where the memory lives.
Because while, services should be stateless, systems should not be forgetful.
So. moving forward, let’s build systems that remember.
Let’s build systems that grow.