Bet on Optionality
Bet on Optionality
Most AI engineers are building themselves into a corner. They pick a use case, build a system for it, ship it, and move on to the next one. Every new problem gets a new pipeline. Every new workflow gets a new agent.
This works until it doesn't. And it stops working faster than you think.
The alternative is to bet on optionality: build AI systems that can handle the thing you haven't thought of yet.
Here's what that looks like.
1. The branches you can't predict
When you model your systems as context (a database, an API, a server, a blog), you're not building for one task. You're building a tree of possibilities. Each module you add creates new branches, new combinations, new capabilities that emerge without you designing them.
Everything is Context
|
+-----------+-----------+
| | |
[DB] [API] [VPS]
| | |
+-----+-----+ | +------+------+
| | | | | | |
query edit join | deploy inspect logs
| | |
+----+----+
|
"tasks you never designed for"
You didn't plan for "query the database and cross-reference with server logs." You didn't plan for "edit a blog post based on what's running in production." But when everything is context, these tasks just work. The agent figures out the path.
The engineers who hardcode workflows only get the branches they drew on the whiteboard. You get every branch the tree can grow.
2. One agent or twenty
There are two ways to build AI systems. Most teams pick the left side.
HARDCODED WORKFLOWS EVERYTHING IS CONTEXT
================== =====================
+---------+ +---------+ +-------+
| Support | | Deploy | | |
| Agent | | Agent | | Agent |
+----+----+ +----+----+ +---+---+
| | |
+----+----+ +----+----+ +-------+-------+
| Zendesk | | AWS SDK | | | | | |
+---------+ +---------+ [m] [m] [m] [m] [m]
| | | | |
+---------+ +---------+ DB API VPS Blog ...
| Billing | | Metrics |
| Agent | | Agent | any module talks to any module
+----+----+ +----+----+ N modules = N! possibilities
| |
+----+----+ +----+----+ vs.
| Stripe | | Grafana |
+---------+ +---------+ N agents = N capabilities
N tasks = N agents
On the left, every new task requires a new agent, a new integration, new glue code. The support agent can't deploy. The deploy agent can't check billing. They live in silos.
On the right, one agent sees everything. The agent is the integration layer, not your code. You never write glue between your database and your server. You expose both as context and the AI joins them when the task requires it.
N specialized agents give you N capabilities. N context modules give you the entire combinatorial space.
3. Adding is multiplying
This is the part most people miss. When you add a context module, you're not adding one capability. You're multiplying.
Modules added over time:
+1 [DB] .
+1 [API] . .
. .
+1 [VPS] . . .
. . .
. . .
+1 [Blog] . . . .
. . . .
. . . .
. . . .
Capabilities: 1 3 6 10 ... n(n-1)/2
^ not linear. combinatorial.
One module gives you one thing. Two modules give you three: each one solo, plus the combination. Three modules give you six. Four give you ten.
This is why the "everything is context" approach pulls away over time. The specialized approach scales linearly (one agent per task). The context approach scales combinatorially (each module amplifies every other module).
Your fifth module doesn't add one capability. It adds four new combinations with every module that came before it.
4. The cost of specializing too early
Here's how teams lock themselves in:
DAY 1: "We need a support bot"
|
v
WEEK 2: Build RAG pipeline for docs
|
v
MONTH 1: Add Slack integration, custom chains
|
v
MONTH 3: New use case arrives
|
v
+---------------------------+
| "That would require a |
| whole new system" |
+---------------------------+
vs.
DAY 1: Make docs a context module
WEEK 2: Make Slack a context module
MONTH 1: New use case arrives
|
v
+---------------------------+
| "That's just a prompt" |
+---------------------------+
The specialized team built a support bot. It works great. But the architecture only knows how to do one thing. When the next use case shows up, they're starting from scratch.
The context team built modules. Docs are queryable. Slack is readable. When the new use case shows up, it's a new prompt over existing context. No new system. No new pipeline. Just a different question asked to the same agent with the same modules.
The difference between "that would require a whole new system" and "that's just a prompt" is the entire gap between building for today and building for optionality.
5. Snap in, don't rewire
This is what optionality looks like in practice:
+========================================+
| AGENT RUNTIME |
+========================================+
| | | |
+--------+--------+--------+--------+
| DB | API | VPS | Blog | <-- context modules
+--------+--------+--------+--------+
| query | CRUD | deploy | posts |
| edit | auth | logs | notes |
| join | webhk | procs | likes |
+--------+--------+--------+--------+
snap in a new module = new capabilities
no rewiring. no new agent. just context.
Each module is self-contained. It declares what it can do, what secrets it needs, and how to talk to it. The agent runtime loads whatever modules are relevant and works across them.
Want to add a new system? Write a module. It immediately composes with everything else. No rewiring the agent. No updating chains. No touching existing code.
Want to remove a system? Unplug the module. Nothing breaks.
This is the architecture that bets on optionality. Not because you know what you'll need tomorrow, but because you've built a system that doesn't need to know.
The bet
The engineers building specialized AI workflows are betting they know what tasks matter. They're probably right today. But the landscape shifts fast, and every pivot costs them a new system.
The engineers building everything as context are betting on flexibility. They're betting that the system that can handle the most tasks wins, including the ones nobody's thought of yet.
That's not a hedge. That's the highest-conviction bet you can make when the future is uncertain.
Bet on optionality.