Forem: Ks22ss

Deterministic Pipeline Orchestration vs. Dynamic Emergence Swarm

Ks22ss — Fri, 10 Apr 2026 10:25:42 +0000

Everyone is building multi-agent systems right now. Most of them will fail in production — not because the models are bad, but because the architecture is chaos.

There is a fundamental debate happening in AI engineering right now, and if you’re not thinking about it before you ship, you will think about it at 3AM when your “autonomous” agent decided to rewrite your database schema because it felt like it.

The debate: Orchestration vs. Swarm.

Let me break it down in terms that actually matter for production systems.

Think of it this way.

Orchestration is trading algorithm. Every move is defined. Every risk parameter is hardcoded. The system does exactly what you designed it to do, no more, no less. It’s boring. It’s predictable. It makes money.

Swarm is a group of floor traders given a goal and told to figure it out. Loud, creative, occasionally brilliant — and occasionally they blow up the fund because one guy made a unilateral call nobody authorized.

Both have a place. The problem is most developers reach for the swarm because it feels more powerful. It isn’t. It’s just less predictable.

Orchestration

Orchestration means you define the flow. Agent A finishes, hands off to Agent B, which hands off to Agent C. The state machine is explicit. You — the developer — control the transitions.

Here’s what that buys you:

Reliability. When your state lives in physical files (Markdown, JSON, whatever), agents cannot hallucinate project progress. The Builder can’t claim it “already did” the Reviewer’s job if the review file doesn’t exist on disk.

Cost control. You know exactly how many API calls happen per cycle. There is no risk of two agents getting into a polite deadlock that drains your credits overnight. I’ve seen swarm systems burn $200 in a single runaway loop. Orchestration doesn’t have runaway loops — it has a script that stops.

Debuggability. When something breaks, you know exactly who dropped the ball. “The Reviewer was too lenient on step 4.” Not “…something in the agent graph went sideways around step 4, maybe, we think.”

The real downside: rigidity. If your pipeline needs a 6th persona — say, a UI Designer that wasn’t in the original spec — you go back and update the loop and the configuration manually. There’s no magic adaptation.

Swarms

In a swarm, you give a Manager agent a set of tools — the other agents — and a goal. The Manager decides who to call and when.

This is genuinely powerful for the right use cases:

Flexibility. The Manager can spin up three Builder instances if the task is complex, or skip the Reviewer entirely if the task is trivial. It scales to the work.

Discovery. If your goal is vague — “make this UI better” — a swarm might surface combinations you didn’t think to hardcode. A design agent and a dev agent brainstorming together can find solutions you wouldn’t have scripted.

The real downside: context drift. Without physical state files, swarms frequently lose the thread after 20-30 minutes of context. The Master gets so deep into a sub-task that it forgets the original goal. I call this the Agentic Loop Trap — the agents are busy, they’re calling each other, tokens are flowing, and nothing is actually getting done. Or worse, something is getting done that you never asked for.

Short Comparison

	Orchestrated	Swarm
Logic Flow	Deterministic (A → B → C)	Heuristic (Manager decides)
Persistence	File-based (survives restarts)	Memory-based (fragile)
Autonomy	Managed, guardrailed	High, unpredictable
Best For	Long-term production builds	R&D, brainstorming, prototyping
Failure Mode	The script stops	The agents loop forever

Read that failure mode row again. One of them stops. The other one loops forever.

For 24/7 Production: You Want Orchestration

This isn’t a preference. It’s an engineering requirement.

In a business context, you cannot afford for a Manager agent to decide at 3AM that it wants to refactor your entire backend because it read something interesting in a sub-task. You need an audit trail. You need to know which agent touched what, when, and what it produced. You need the system to stop, not drift.

Orchestration gives you that. Swarms don’t — not by default, and not without significant engineering overhead to get there.

The Hybrid Sweet Spot

Here’s where it gets interesting.

The most sophisticated systems don’t pick a side. They use orchestration for the high-level flow, but allow individual execution agents to act as “mini-managers” for their specific domain.

The Governor controls the pipeline: Planner → Builder → Reviewer → Deployer. That flow doesn’t change.

But the Builder? Inside its execution context, it can spawn sub-agents, delegate sub-tasks, and make local decisions — as long as it hands back a concrete artifact when it’s done.

You get the auditability and cost control of orchestration at the top level, with the flexibility and creativity of a swarm contained inside well-defined boundaries.

That’s the architecture worth building.

Final Words

If you are shipping a production system that runs overnight, handles real users, or costs real money — start with orchestration. It’s not boring. It’s engineering.

Swarms are a research tool dressed up as a production pattern. They’re great for exploring solution spaces, terrible for running a business on.

Build the guardrails first. Give your agents room to be creative inside them. And for the love of everything, put your state in files — not in context windows that evaporate the moment something crashes.

Patterns of Inefficiency in Enterprise and a Lean Alternatives - Part 1

Ks22ss — Thu, 09 Apr 2026 07:25:48 +0000

I’m a developer who spent 3 months embedded across multiple enterprise project deliveries. Here’s what I noticed.

The Principal-Agent Problem and Information Asymmetry

When the person managing a vendor can’t evaluate what the vendor actually produces, the vendor holds all the information power. That’s the principal-agent problem — and it’s quietly expensive.

Picture an IT manager who can’t read a codebase reviewing a vendor’s delivery. All he can do is click through the UI, test a few functions, and see if things appear to work. He signs off, hands it to the end users, and moves on.

Two weeks later — server down. Something crashes. Users escalate to the IT manager. The IT manager turns to the vendor. The vendor says it’s fixed. The IT manager relays that upstream.

Sound familiar? This cycle plays out constantly in enterprise environments. And here’s the uncomfortable truth: it didn’t happen by accident.

Why Companies Do This Intentionally

Hiring non-technical managers to oversee vendors isn’t stupid. It’s a deliberate tradeoff.

Non-technical managers are cheaper to hire, easier to replace, and often genuinely excellent at stakeholder communication. They smooth relationships, manage expectations, and keep projects politically on track. Under normal conditions, with stable budgets and reasonable vendor quality, this model works well enough.

The problem isn’t the model itself. The problem is what happens when conditions change.

When Budget Constraints Hit

Economic downturn. Layoffs. Budget cuts. Meanwhile, users demand more projects because their own workloads increased and they need tools to keep up.

The IT manager is now two to three times busier — not building anything, just coordinating. More vendors. More communication. More handoffs.

And vendors, sensing the pressure, don’t get cheaper in any meaningful way. Discounts come with quality reductions. Inflexibility increases. The vendor knows you need them, and they know you can’t fully evaluate what they deliver.

This is where the bottleneck becomes visible — but by then it’s already expensive.

The "Number" That Nobody Questions

A simple enterprise form submission app. Static frontend, a serverless function, hostable on an S3 bucket for near zero ongoing cost. Straightforward for any competent developer to build in days.
Six figure budget. One month timeline. Approved.
Why? Because the IT manager doesn’t know what it should cost. The end user doesn’t know.

Only the vendor knows — and the vendor has every incentive to keep it that way.

This isn’t a vendor problem. It’s an information asymmetry problem. And it compounds quietly until a budget crisis makes it impossible to ignore.

The Structural Issue

Most enterprises separate technical execution from technical oversight entirely. Under normal budgets, this is manageable. Under constraints, it becomes the most expensive decision you never noticed you made.

CEOs tend to underestimate in-house builders and overestimate vendor output. When both are happening simultaneously during a budget crunch, bad outcomes don’t just add — they multiply.

The No-Code Trap

Budget is tighter now. Outsourcing everything to vendors isn’t sustainable. So the IT manager thinks creatively — and lands on what sounds like a brilliant middle ground.

No-code. Low-code. Power Automate. Power Pages. Let the platform do the heavy lifting.

On paper, this makes sense. Microsoft manages the infrastructure. Licensing is predictable. Non-technical staff can theoretically build and maintain workflows without developer involvement. The IT manager can stay in control without needing to understand what’s happening under the hood.

It works. Until it doesn’t.

The Walls Users Hit

The first wall is customization. Users start with simple requirements, get comfortable, and then inevitably ask for more.

Can it do this?
Can we add that condition?
What if the input looks like this instead?

No-code platforms are excellent within their boundaries. The boundaries just aren’t visible until you’re already against them.

The second wall is performance.

A Power Automate flow with enough conditions and connectors can take three hours to process something a simple script handles in seconds.

Nobody told the users that when they started building.

By the time they notice, hundreds of records are already running through a pipeline nobody wants to touch.

The third wall is auditability.

When security or compliance teams ask how data is being handled, who has access, where credentials are stored — the answer gets uncomfortable fast. Low-code platforms abstract away exactly the things auditors want to see. Source code is hard to produce. Logic is buried in visual flow diagrams. The IT manager can’t answer the question, and neither can the platform documentation.

The fourth wall is the one future developers hit.

A new developer joins, opens the workflow tool, and stares at a canvas with a thousand connected actions, nested conditions, and branching trees built by five different people over eighteen months with no documentation and no naming conventions. Developer call this "Spaghetti".

There is no architecture. There are no layers. There is just accumulated decisions, each one reasonable at the time, collectively forming something nobody fully understands anymore.

This is technical debt — just dressed up in a drag-and-drop interface.

The Misunderstood Promise of Low-Code

Low-code platforms are genuinely excellent at one thing: integrating with existing ecosystems. Power Automate connecting Microsoft products together is a legitimate use case. It saves time, reduces friction, and doesn’t require custom development for straightforward workflows.

But that’s not how it gets used under budget pressure. Under budget pressure, it becomes a construction tool for complex business logic, a replacement for proper application development, a way to avoid hiring developers. And that’s where the promise breaks down.

Because low-code doesn’t mean no skill required. It means the skill required is less visible — until the system breaks, scales, or needs to change. A competent developer, especially today with AI dramatically amplifying individual output, can build what these platforms produce with more flexibility, better performance, full auditability, and architecture that a future developer can actually reason about.

The platform abstraction isn’t free. You pay for it in constraints you don’t see coming.

Back to the IT Manager

So the vendor route got expensive. The no-code route hit its ceiling. What’s left?

The IT manager calls a meeting with the users.

“You know, some of this you could probably just… do manually, right?”

The room goes quiet.

Everyone smiles politely. Nobody says what they’re thinking.

And the backlog keeps growing.

Patterns of Inefficiency in Enterprise and a Lean Alternatives - Part 2

Ks22ss — Thu, 09 Apr 2026 07:25:27 +0000

What follows isn’t a proven framework. It hasn’t been battle tested in production. It’s a direction I’ve been thinking about — born directly from the patterns I described in Part 1. Take it as a proposal, not a prescription.

The Smallest Viable Unit

Every problem in Part 1 traces back to the same root cause:

people making decisions couldn’t evaluate what was being built.
Vendors exploited that gap.
No-code platforms obscured it. And eventually the IT manager ran out of roads.

So what’s the minimum viable team that closes that gap — without blowing the budget?

I think it’s three.

One Business Analyst
One Developer
One AI Agent

I call this "TripleOne" — the smallest unit capable of delivering real enterprise high quality in house software in a budget-constrained environment.

The Three Roles and Why Each One Matters

The Business Analyst is not just someone who talks to users. In this model, the BA is the translation layer between user chaos and developer clarity. Users don’t know what they want in technical terms — they know what problem they have. The BA’s job is to capture that, structure it into clear requirements, and protect the developer from scope creep and moving goalposts. Without this role, developers build the wrong thing precisely and efficiently. With it, every build starts with a shared understanding of what done actually looks like.

The AI Agent writes the code. This is what makes TripleOne modern and distinct from just “hire a small team.” A competent developer paired with AI can produce what used to require three to five engineers. The agent handles boilerplate, accelerates implementation, and reduces the time between requirement and working software dramatically. This isn’t hypothetical — it’s already how the best lean engineering teams operate today.

The Developer is not just a coder in this model. The developer is the technical conscience of the unit. They oversee what the agent produces, make architectural judgements, catch what AI gets wrong, and ensure the system is maintainable by the next person who touches it. This is precisely the role that was missing in Part 1 — someone who can actually evaluate output, ask hard questions of vendors, and know when a six figure estimate for an S3 hosted form app is absurd.

Together these three roles directly answer the failures from Part 1. The information asymmetry shrinks because technical oversight is built in. The vendor dependency reduces because the team can build in-house. The no-code ceiling disappears because the team writes real code with real architecture.

One Platform, Not One App

The “one app” in TripleOne is probably the most important thing to get right — and the easiest to misunderstand.

It doesn’t mean you build one thing and stop. It means you build one centralised platform that everything else grows from.

Here’s what that looks like in practice.

The platform starts with an Auth Module — a single source of truth for user identity and role based access control. Every module that gets added inherits this. Users are authorised once, centrally, with clear permission boundaries. No more separate login systems per tool, no more credential sprawl, no more security audits that produce uncomfortable silences.

The frontend is a NextJS/React application built and hosted on S3 — simple, fast, very cheap to run, and easy to extend. Built on JAMstack principles, it separates the presentation layer cleanly from the business logic. Adding a new user-facing module means adding to this application, not spinning up something new from scratch.

The backend uses serverless functions for the API layer — scalable by default, again, very cost efficient at low to medium load, and straightforward to reason about. One SQL database handles relational data. Object storage handles files and assets. Roles and responsibilities are clearly separated at every layer.

When a user requests a new application, the answer isn’t “find a vendor” or “let’s see what Power Automate can do.” The answer is: add a module. One new frontend section. One new set of backend functions. Plugged into the same auth, the same database structure, the same deployment pipeline.
The platform compounds over time. Every module added makes the next one faster to build. The architecture stays coherent because one developer is making the judgement calls throughout. The BA ensures every addition is grounded in what users actually need.

What This Solves — And What It Doesn’t

TripleOne isn’t a silver bullet. A few honest caveats before anyone tries to implement this.

It requires the right developer. Someone who can work with AI effectively, make sound architectural decisions, and resist the pressure to cut corners when timelines tighten. That person exists — but finding them matters enormously.

It requires organisational trust. The IT manager, the department head, the budget approver — someone in the chain needs to believe that one developer with AI can outperform a vendor team. That’s a cultural shift, not just a technical one. In many enterprises, it’ll be the hardest part.

And it doesn’t fix the oversight problem on its own. If the same non-technical manager is still approving scope and signing off on delivery, some of the information asymmetry remains. TripleOne works best when the developer has a direct line to stakeholders — not filtered through layers of people who can’t evaluate what they’re seeing.

Why I Think This Direction Is Worth Exploring?

Enterprise software doesn’t have to be expensive to be good. It doesn’t require six vendors, a no-code platform hitting its ceiling, and a backlog full of things users were told to do manually.

The tools exist today to build maintainable, secure, scalable applications with a team this small. AI has genuinely collapsed the minimum viable team size for software delivery. The architecture patterns are proven — startups have been building this way for years.

What’s missing in most enterprises isn’t budget. It’s the belief that a leaner path is possible.

TripleOne is my rough attempt to sketch what that path looks like. It needs refinement. It needs people smarter than me to poke holes in it. It needs someone brave enough to actually try it.

But every framework starts as someone’s half-formed idea written down.