Himanshu Yadav — Systems Builder | AI Architecture, Platform & Quantitative Engineering

The mission

Fusion AI Ecosystem.

These aren't side projects. They're nodes in one mission: make AI genuinely capable of running things — companies, capital, and eventually the physical world. Fusion Legions is where that becomes a business; everything else is the layer it stands on.

The agent type

ATLAS — A Truly Living Autonomous Soul

ATLAS is a type of agent, not a single one. The first agent built to that type is also called ATLAS — and it won't be the last. Because the framework underneath is mine, the type isn't bounded by what someone else's abstractions allow: there can be many ATLAS-type agents, each with its own personality, purpose and domain.

◐ in development

Fusion Legions

AI-native done-for-you services. Until now, AI helped you do the work — and when you needed it actually done, you hired an agency. Legions is built the other way round: the work comes back finished, delivered by a workforce of specialised agents instead of a floor of people.

Two ways to work with it: managed, where the legion is run for you and outcomes come back finished, or embedded, where it runs inside your own organisation.

◐ in development

Fusion Edge

The quantitative platform — research, alpha generation and agentic execution, with the depth to connect a broker and bring your own models in. Currently proprietary: it runs my own research, not anyone else’s capital.

That’s design intent, not a track record. It’s in development, no validated performance is claimed, and nothing here is investment advice or a managed-money offering.

◐ in development

Fusion Framework

The foundation everything else stands on — the primitives, protocols and execution model the rest composes from. Not a wrapper over someone else’s abstractions.

◐ in development

Fusion Forge

Where agents are actually created — not from the framework directly, but through Forge. The same category as Claude Code, Hermes and OpenClaw, with many more layers of orchestration, and built to take what works in each of them and go further.

○ direction

Fusion Dynamics

The physical dimension. Once agents can reliably do the thinking work, robotics is how they act on the real world.

Framework and Forge aren’t products — they’re the base. They sit with Fusion AI itself and everything commercial is built on top of them. That’s the whole point of building the foundation rather than renting someone else’s: what Legions can deliver isn’t capped by what another company’s abstractions allow.

All of it runs on infrastructure I own and operate — a self-managed Kubernetes platform on my own hardware, private by default, with nothing internal exposed to the public internet. That part is running today. It's the floor the rest is built on, not the achievement.

Every branch carries its real status: three are being built now, two are stated direction and not products. I'd rather you know exactly which is which than have to guess.

How I think

The same loop, applied to almost everything.

This isn't a methodology I adopted — it's just how I approach a system I don't like. It's why my background looks like a zigzag and isn't one.

Understand the system → redesign it → automate it → make it intelligent → move on. Applied to a business process, a trading strategy or a Kubernetes cluster, the loop is the same.

Positions

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

Opinions are cheap when they're untested. Each of these cost me a build, and each one changed how I work. I'd rather you disagree with a specific claim than nod along to a stack list.

01

Most "agent frameworks" are prompt chains with state bolted on.

I evaluated n8n with LangChain, Botpress on LangGraph, Flowise and CrewAI firsthand — not from blog posts. Underneath the abstractions, most of it is a chain of prompts with memory attached. That's fine for a demo. It falls apart when you need real boundaries, defined failure modes, and controlled execution against production systems.

So I stopped looking at libraries and started looking at harnesses. The reference points that actually hold up are Claude Code, Codex, Hermes and OpenClaw. That's the category Fusion Forge is built into — many more layers of orchestration, configuration and adaptive memory — not a bag of parts for assembling an agent.

02

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

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.

03

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.

04

Private by default, or you're renting someone else's defaults.

Everything I run sits behind zero-trust access on a private mesh, with self-hosted identity, self-hosted secrets and self-hosted git. Not paranoia — it's that if you don't own the identity layer and the secrets layer, your security posture is whatever a vendor decided it should be this quarter, and you'll find out when it changes.

05

The interesting problems live between the layers.

A specialist stops looking at the boundary of their layer. That's exactly where the real problem usually is — the thing that's slow isn't the query or the network or the scheduler, it's the interaction between them that nobody owns. Breadth isn't a lack of depth; it's what lets you see the problem that the specialists on either side have each correctly ruled out of their own scope.

Build notes

Longer form, from the actual work.

Write-ups of decisions I had to make properly — what I tried, what I rejected and why. Written while building, not afterwards for a portfolio.

Why I stopped evaluating agent frameworks and wrote my own

agents · MCP · A2A

I went in wanting to adopt something. Four frameworks later I understood why I couldn't.

Read →

I went into this wanting to adopt something. 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 n8n today 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 storage — Milvus and SurrealDB among others; it's one building block, not the story. Model access is multi-provider — OpenAI, Claude, Grok, Ollama — because locking the model layer to one vendor is an avoidable risk.

What came out of it is two layers. The Framework is the foundation — primitives, protocols, execution model. Fusion Forge is the harness on top, and where agents are actually created: the same category as Claude Code, Codex, Hermes and OpenClaw, with many more layers of orchestration. A library hands you pieces to assemble an agent; a harness decides how the agent thinks, remembers and is allowed to act.

It's still in development. I'd rather say that than call it finished.

A private cloud on two nodes

platform · zero-trust

Self-hosting this isn't about cost. It's about who owns your failure modes.

Read →

Everything I build runs on infrastructure I own and operate: a self-managed RKE2 Kubernetes cluster on my own hardware.

Delivery is GitOps through Argo CD. Infrastructure and workloads are both managed as code, which means the cluster's state is something I can read in a repository rather than something I have to remember.

The platform layer: Traefik for ingress, Authentik for SSO, OpenBao for secrets, self-hosted Gitea with CI/CD, KubeVirt for virtualised workloads including Windows Server 2022, and Longhorn for storage.

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.

People assume self-hosting this is about cost. It isn't. It's that 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, and you find out they changed when something breaks. Owning it means the failure modes are mine — worse in the moment, considerably better over time. It also means that when I build something on top of it, there's no layer of the stack I can't inspect.

Killing MailWizard

product · judgment

It shipped and it worked. That wasn't the problem.

Read →

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 personalization 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 many VPS, with three GlusterFS nodes for distributed storage.

It shipped and it worked. That wasn't the problem.

The problem was the category. Email marketing is saturated with well-funded products doing the same job, and I didn't have a wedge sharp enough to matter to someone already paying for one of them. Building more features wouldn't have fixed that — it would have produced the same product, later, with more sunk cost attached to the decision.

So I stopped.

I write about it rather than quietly dropping it from the record. The engineering was real, and the list-hygiene and deliverability work is knowledge I still use. But the more valuable thing it taught me was how to tell the difference between a project that isn't working yet and one that isn't going to — and to act on that while the cost is still only time.

The code is still private. I may open-source it at some point; it hasn't happened yet.

Shipping is a skill. Stopping is a different one, and it's the one most builders are shorter of.

Where I work

The problems I'm drawn to.

A pattern across everything below: I'm most useful where the architecture or the implementation route hasn't been figured out yet — greenfield systems, AI projects stuck before production, and infrastructure that has to survive contact with reality.

01

AI systems that reach production

Most AI projects die between the demo and the deploy. The part that kills them is the part I work on: integration with real systems, observability, permissioning, cost control, and a runbook someone else can operate.

02

Platform and infrastructure

Kubernetes built properly — GitOps delivery, self-hosted identity and secrets, zero-trust networking. Not just deploying onto a cluster; building and running the cluster.

03

Agentic systems

Agent orchestration, tool integration and controlled execution — designed as engineering, with boundaries and failure modes, rather than a prompt wrapped in optimism.

04

Quantitative engineering

Market data pipelines, tick-level research environments, execution and position management. Both the infrastructure and the domain — a rarer combination than it sounds.

05

Automation and leverage

Finding the repetitive human work inside a process and removing it with software, agents and infrastructure — usually after redesigning the process rather than automating a bad one.

06

Rescue and redesign

Systems that already exist but don't work well enough. Bottlenecks, weak abstractions, operational pain. Frequently the highest-value work available.

The path here

I followed the problem down the stack.

Business & process→ Software→ Infrastructure→ Automation→ AI & agents→ Quantitative systems

I started on the business side — consulting, operations, people-heavy work. What I kept finding was the same thing everywhere: processes broken in ways nobody had bothered to look at, held together by people doing repetitive work that shouldn't have needed doing.

Every time I tried to fix one properly, the real problem turned out to be 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.

That's how I ended up here — not by career planning, but by following the problem down until I hit the bottom of the stack and found it was the most interesting place to be. Every layer I went through, I had to learn properly enough to build in. That's the breadth, and it wasn't accumulated on purpose.

Since 2022 I've mostly built my own things: a digital services business I tried and failed to productize into SaaS on GoHighLevel and similar platforms, an email marketing platform with AI personalization built into the send pipeline, and a PikaPods-style managed hosting service for open-source software that landed a large enterprise client. I also led development of a reverse-auction marketplace for an early-stage startup. Some worked, some didn't — every one of them got built and put into the world rather than staying an idea.

The honest read on the ones that didn't: the constraint was never building the thing. It was distribution and sales — the part that rewards a different kind of person than I am. I'm a builder. Given the resources, there is very little I wouldn't take on.

None of this started as a career. Tech has been the hobby since long before it paid for anything — soldering and circuit work, 3D printing, reballing Xeon CPUs, pulling apart consoles and phones to find out how they worked and whether they could be made to do more. The through-line hasn't changed: take the thing apart, understand it properly, then make it better than it was.

The Fusion AI Ecosystem is what happens when that loop stops being applied to other people's problems and starts being applied to the thing I actually want to exist.

The invitation

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

Fusion is deliberately larger than one person can finish, and I'd rather it be built well than built alone. If you read the positions above and either wanted to argue with one, or found you'd arrived at the same conclusion independently — you're the person I want to hear from.

Engineers, researchers, operators, people who've built something hard and know what it actually costs. Tell me what you're working on.

himanshu@atlasfusion.com LinkedIn →