01

Himanshu Yadav · Fusion AI · Noida, India

The problem was always one layer further down.

Fix the process, and the software is wrong. Fix the software, and the infrastructure is wrong. Fix the infrastructure, and you realise the whole thing should have been automated in the first place.

I kept going until I was building the intelligence itself.

Frameworkwhat an agent is
Runtimewhat executes it
Harnesswhere they are made
Infrastructureowned, not rented

Founder of Fusion AI. Every layer under Fusion Legions is one I own — no per-seat licence caps the economics, and no other company's roadmap caps what it can deliver.

The descent A vertical axis whose measure is stack depth rather than seniority. Six stops descend from process and operations at the surface, through software, infrastructure, automation and agent stacks, to AI and agents at the bottom. The line grows brighter with each step down; the final node is lit and pulsing. Surface Process & operations where it started Software build the tool instead Infrastructure hosting business clients · it paid Automation Open Software Hub operated · 2024 Agent stacks four of them, then my own AI & agents Fusion AI · now Depth, not seniority
02

The path here

Every layer I learned, I learned by being stuck on the one above it.

The hosting business is where the infrastructure expertise came from. It ran, it had clients and it paid — and operating other people's open-source software at scale is exactly the education that now lets me run a private Kubernetes platform end to end.

Having built that competence, the interesting move was up the stack rather than sideways: build the intelligence instead of hosting someone else's software. That decision is the reason Fusion AI exists at all.

Across all of it the pattern was consistent: building was never the constraint. Repeatable distribution is — landing one customer is not a channel. Knowing that before starting rather than after is why Legions is shaped the way it is.

Tech was the hobby long before it paid for anything — soldering, 3D printing, reballing Xeon CPUs, taking consoles and phones apart to see whether they could be made to do more. The through-line hasn't changed: take it apart, understand it properly, make it better than it was.

03

Positions

Things I've concluded by building, not by reading.

Each of these cost something to learn. They carry a date because a position without one is just an opinion, and because you should be able to see which ones are recent.

2026·06

Frameworks are prompt chains. Harnesses are the real category — and none of them is extensible enough.

Two different things get called the same word. I built with n8n and LangChain, Botpress on LangGraph, Flowise and CrewAI — underneath the abstractions, most of it is a chain of prompts with memory attached. Fine for a demo, and it falls apart the moment you need real boundaries, defined failure modes and controlled execution against production systems.

The harnesses are the ones that hold up, and I use them every day — Claude Code, OpenAI's Codex CLI, Hermes, OpenClaw. Genuinely good at what they are for: one operator, one session, developer work. What none of them is built for is a persistent multi-role workforce holding a job against business systems for months — and none of them is mine to extend when it stops fitting.

2026·05

AI agents multiply implementation. They don't multiply judgement.

I use coding agents heavily and they've changed my throughput enormously. What they haven't changed is who owns the architecture, the review, the tests, the integration and the thing at 3am when it breaks. That stays with me. The engineers who get burned by AI tooling are the ones who let it make decisions instead of letting it execute them.

2026·04

Signal quality is the overrated half of the problem.

A finding from my own research that surprised me: how good the entry signal is often matters less than what happens after the entry. Execution and post-entry management frequently dominate the outcome. It generalises well beyond trading — most systems are limited by what they do under load and after failure, not by how good the happy path looks.

2026·08

Distribution is the constraint. I learned that by building, and designed around it.

I have shipped products that worked technically and learned, twice, that building is the easier half. Go-to-market is not something a good product takes care of on its own — it is a design constraint, and it belongs at the start rather than the end.

So Legions is built around it. It sells a finished outcome rather than a tool: the buyer already carries an agency line in the budget, so the spend exists and the comparison is to an agency's output rather than to a category that has to be explained first. I'm stating that as a hypothesis I intend to test early rather than a conclusion.

04

Build notes

What I tried, what I rejected, and why.

The positions above are the conclusions. These are the receipts.

Aug 26

MailWizard, and how you read a category

I shipped it, it worked, and the most useful thing it taught me had nothing to do with code.

Expand

MailWizard was an AI-native email marketing platform. I built it end to end and shipped a working V1: self-hosted Mautic underneath, bulk list verification and cleaning, and AI personalisation wired into the send pipeline itself — a Haraka MTA queueing every message to RabbitMQ, enriched and rewritten before delivery. It ran on a Docker Swarm cluster I built by hand across several VPS instances, with GlusterFS for distributed storage and cluster traffic isolated from storage traffic on separate private networks.

This was 2023, before coding agents were good enough to lean on. Every line of it was hand-written.

What it taught me was how to read a category. Email marketing is saturated with well-funded products doing the same job, and more features would only have produced the same product later. That is a judgement you can only really learn by having built the thing and being close enough to see it clearly.

So I redirected the effort while it was still only time, and took the whole build with me. The MTA work, the list-hygiene and deliverability engineering, and the distributed-cluster experience are all knowledge I use now.

The durable skill is telling the difference between something that isn't working yet and something that won't — and acting on it early. That judgement is what I brought into Fusion.

Shipping is a skill. Knowing where to point it next is a different one, and it compounds faster.

Jun 26

Four agent stacks in, and why I built my own

I went in wanting to adopt something. Four stacks later I knew exactly what to build.

Expand

Writing your own framework is a real cost, and the ecosystem looked mature enough that building one seemed unnecessary.

I worked through n8n with LangChain, Botpress on LangGraph, Flowise and CrewAI — building with each of them rather than reading about them.

What I found underneath the abstractions was consistent: a chain of prompts with memory attached. Flowise made it clearest — visually it's a graph, but what it's composing is a sequence of prompt steps. That isn't a criticism of what those tools are good at. n8n with memory is genuinely useful for workflow automation, and I still use it as a tool my agents call. But there's a difference between orchestrating workflow steps and giving an agent controlled execution against production systems.

The gap that mattered was boundaries and failure modes. Once an agent has real tool access — infrastructure, data, execution — the question stops being "does it produce good output" and becomes "what is it permitted to do, what happens when a tool call fails, and can I reconstruct what it actually did." Most of what I tested treated that as an afterthought.

So what I built is organised around exactly that. Agents call tools through MCP and A2A, direct APIs where that's simpler, and workflows where a workflow genuinely is the right shape. Retrieval runs on vector search — Milvus, and SurrealDB where the multi-model shape fits better. Model access is multi-provider because locking the model layer to one vendor is an avoidable risk.

What came out of it is a stack, not a library. It's still in development.

Jul 26

Why I own the metal

Running my own infrastructure was never about cost. It is about what it makes possible next.

Expand

Everything I build runs on server clusters I own and operate, not on rented capacity. RKE2 for the cluster, GitOps delivery through Argo CD, Authentik for identity, OpenBao for secrets, self-hosted Gitea for source and CI, and KubeVirt where a workload needs a full VM rather than a container.

Infrastructure and workloads are both managed as code, so the state of the platform is something I can read in a repository rather than something I have to remember — which is what makes it expandable rather than precious. Adding capacity is a config change, not a migration.

The part I'd defend hardest is the access model. Internal services sit behind zero-trust access on a private mesh. Nothing internal is exposed to the public internet — not a dashboard, not an admin panel, nothing.

If you don't own the identity layer and the secrets layer, your security posture is whatever a vendor's defaults happen to be this quarter. Owning it means every layer of the stack is one I can inspect, change and scale on my own schedule.

That is the point. Agents need real permissions against real systems, and you can only grant that safely inside an environment you control end to end. The platform is built to grow into what Legions needs at volume, not sized to what it needs today.

05

What I've built

One boundary, and I own everything inside it.

Most companies in this space rent the intelligence and compete on the wrapper — which works right up until the model provider ships the wrapper. What Fusion Legions can deliver is bounded by engineering, not by another company's abstractions, licence terms or roadmap.

One honest exception, drawn in the diagram: model access crosses the boundary. That is deliberate and it is multi-provider, because tying the model layer to a single vendor is the one avoidable risk in the whole design.

The boundary A boundary labelled self-managed Kubernetes contains the framework, the runtime and the harness, with the platform beneath them. A single dashed line crosses the boundary from a box outside it labelled model providers, multi-provider by design. Self-managed Kubernetes — mine Framework what an agent is Reactor the runtime that runs it Forge where agents are made Platform · identity · secrets Model providers multi-provider by design
Fig. 01 — One line crosses the boundary, and it is the one I chose to leave open.
ComponentWhat it isStatus
Framework What an agent is — identity, capability, memory, persona. A character with continuity, not a config file with a system prompt. Building
Reactor The runtime that executes them. It operates a live desk, infrastructure, research and content every day. Operating
Forge Where agents are made, deployed and coordinated. The role catalog is an org chart you can deploy. Building
Platform RKE2, Argo CD, Authentik, OpenBao, self-hosted Gitea, KubeVirt. Owned hardware, zero-trust access, nothing internal on the public internet. Operating

What this is for is a separate story, and it is told properly on the company site: Fusion AI — the ventures, the structure, and what each one is trying to do.

06

The invitation

I'm building this either way. It moves faster with the right people.

If you invest at this stage

Fusion Legions is the commercial arm and my whole focus; the intelligence layer underneath exists to make it deliver. The next twelve months are one thing: getting Legions delivering. The harness finished to the point where a legion takes a brief and returns finished work without me in the loop. The first engagements landed against a standard written down before the work starts. The first people who aren't me. Infrastructure grown to carry it.

Capital changes the rate, not the direction. Money decides how long it takes, and how much of the market is still open when it arrives.

What I'll discuss, and what I won't

The stack is private and stays private. Framework, Reactor and Forge are the asset, not a feature list — they are what makes the economics work and what a competitor would need years to reach. What I discuss in a room is what they enable, where the work is pointed, and what capital accelerates.

If you're building something yourself

If you read the positions above and either wanted to argue with one, or arrived at the same conclusion independently — you're the person I want to hear from.