Reimagining Agentic Systems
Discovering context and composability
We’re living through a moment of heightened excitement (possibly hype-citement) in the API and AI world.
The Agentic Gold Rush
Frameworks like Langchain, CrewAI, and Auto-GPT are pushing boundaries — blending APIs and LLMs into systems that feel dynamic, exploratory, even alive. The Model Context Protocol (MCP) is especially popular right now. MCP casts agents not as glue code, but as first-class citizens in an evolving network of services.
In general, this is all good news. It means we’re again able to stretch the boundaries of information systems as a mental construct. It means we're seeing the blurring of the lines between AI platforms and API ecosystems.
But : and here's is an important realization:
Many of the core elements of these agentic architectures we're seeing emerge are not only possible with current technologies but also already up and running in one form or another in many enterprises today.
What is at the heart of these agentic platforms? Some basic elements:
The tools to Discover of capabilities
The availability of shared context/state between services
The power of Reversible, retryable interactions
And Composable interfaces that require no prior coordination
These aren't distant dreams — they’re already baked into the many resilient API designs of the past decade. We don’t need to replace what we’ve built. We just need to recognize how close we already are.
Not New, Just Rediscovered
The idea of composable services has deep roots — stretching from the mashup culture of Web 2.0, to the rise of microservices, to today’s lambda-style event-driven platforms.
I’ve written about this set of capabilities for several years — in blog posts, on stage, and especially in my books on RESTful patterns for APIs and clients. Admittedly, I slow-dripped these ideas over the last ten-plus years starting with Building Hypermedia Systems … in 2011, through RESTful Web APIs (2013), RESTful Web Clients (2017), and most recently RESTful Web API Patterns and Practices Cookbook (2022).
In those books, I talk about the flexibility and power of hypermedia, statelessness, and the uniform interface — principles that make it possible to build modular, evolvable, self-descriptive systems at scale. And, no surprise, all that work over the years was laying out the foundation for enabling agentic systems..
Also, there is now growing interest in affordances and the role they play in enabling ecosystems where services don’t just interoperate, but directly interact with other services and, over time, adapt.
Affordance-driven systems let us:
Compose services without direct coupling
Navigate functionality without prior integration
Understand meaning through structure
Adapt service interactions over time
This kind of interactive composability isn’t a new trend. It’s the design language of adaptive systems.
The Three Pillars of Composable Infrastructure
No matter what we call it — affordance-based, lambda-style, agentic, event-driven — the key to building flexible, stable, and decoupled systems usually comes down to the same three elements:
Dynamic Service Discovery
Shared Semantic State
Composable Service Interfaces
Dynamic Service Discovery
For composable, agentic systems to work at scale, all participating services need to broadcast their availability. That means advertising capabilities — not in some static directory or config file, but in a way that clients and jobs can query in real time.
Clients ,whether human or machine, should be able to search and select services on demand, based on what they need to do next. And this should happen dynamically, as the environment changes.
In truly composable systems, the discovery layer becomes an ambient map — one that agents (or "jobs") can consult, traverse, and respond to as they go.
Shared Semantic State
Just as LLMs rely on context to help them interact meaningfully with users, a composable platform depends on a platform of shared state to provide context between independent services.
A shared-state service acts as a semantic substrate — a memory field that jobs can read from and write to. It’s not just data passing — it’s the glue that enables collaboration across time and task boundaries.
Much like the Unix philosophy of pipes and filters, where small programs communicate through standard input and output, a composable platform uses shared, contextual state to make powerful composition possible.
This state makes it possible for humans and machines to build unique, responsive solutions from loosely connected parts without the need to re-write the services they wish to enlist.
Composable Service Interfaces
Inspired by the Unix process model and REST’s uniform interface constraint I outlined (in the 2022 pattern book) a precursor of the Composable Interface Pattern (CIP) I use today. CIP is a simplified model that reduces service interaction to three abstract capabilities:
execute: perform the requested operation
repeat: retry the same action (in case of problems)
revert: undo or compensate for the requested operation
This minimalist interface lowers the cost of reuse and coordination. It allows services to behave more like interchangeable components or autonomous tools without prior integration assumptions. The Composable Interface Pattern gives each service a minimal yet complete and stable contract that other services can rely upon. This reduces the work of service coordination ahead of time, it allows developers to focus on what really matters (execute, retry, or reverse), and makes it easier to enlist independently-created services into a single solution (or job).
From JCL to MCP
Today, composable systems often rely on orchestrators to "drive" the process — calling services, mixing their responses, and ultimately solving a problem. Most of these systems are imperative programming languages unto themselves. The same is true for agentic systems: someone has to come up with the script, the template, the plan.
In the early days of computing, this work was handled by a job control language — JCL for short. That model still holds up. What's needed now is a full-featured, reliable declarative job control system for the web — something that works like a Unix shell, but for distributed service ecosystems.
Our web-centric JCL should:
Accept declarative job definitions as input
Execute steps in a sequence, each with one or more parallel tasks
Route outputs to shared state that can be used later
Support retry and reversal at any point in the process
Allow jobs to respond dynamically based on runtime conditions
Each job document becomes an agent capable of perceiving (via shared state), reasoning (via conditional logic), and acting (via service execution). Think Terraform or Apache Airflow for services on the open web. That is an agentic system.
Ready for the Future
So, what's the message here? For those who have already been working on creating composable systems that support discovery, shared-state, and stable interfaces, the arrival of MCP and other agent-centric platforms is nothing new. And for those who want to take advantage of the oncoming wave of AI-driven API consumption, investing in the three pillars of composable systems is a great way to set yourself up for success.
If you’ve built your services with this pattern — or even just started thinking this way; you’re not behind. You’re early.
“The future is already here — it’s just not evenly distributed.” — William Gibson