I Became the Integration Layer. So I Built Valdr.

I was the integration layer.

Not by choice. By accumulation.

I had three folders — agents/ for long single-shot prompts, prompts/ for snippets I kept pasting, projects/ for a homegrown system of specs, phases, docs, and tasks. They worked for a while. Then they didn’t. And the reason they didn’t is the same reason most serious AI workflows quietly break: not the agents, not the prompts, not the tooling. Me.

I was the one remembering to paste the conventions. I was the one stitching the spec to the task to the agent. I was the one catching the agent when it ignored half the spec because I forgot the right paragraph at the start of the session. The folders weren’t the problem. I was.

Orchestration overhead doesn’t compound. It just costs.

That’s the line that finally pushed me to build Valdr.

The smallest possible step

The first thing I did was the least glamorous: I took the agents, prompts, and contexts from my folders and rewrote them as capabilities. Not refactored. Not redesigned. Just ported — same content, same intent, in a form the system could reason about.

Once it was in capabilities, the duplicates became obvious. Patterns I’d been pasting into three different prompts collapsed into one. Constraints I’d been re-explaining every session became reusable units. The mess didn’t shrink because I removed anything — it shrank because I could finally compose.

Then I built the first workflow: a task executor.

I had tasks. I had agents. I had capabilities. What I didn’t have was a clean way to tie them together — to inject the right capabilities into the right agent and hand it the right task. So that’s what I built first.

This sounds trivial in retrospect. It wasn’t. Formalizing “load this capability set, hand off this task context, launch this session” was the moment I stopped being the integration layer. The system was.

The bottleneck keeps moving upstream

I want to skip ahead to the part that took me by surprise.

The work isn’t one thing. It’s an assembly line:

spec → planning → task creation → execution planning → execution → reviews and quality gates → close out

Every stage on that line has been my bottleneck at some point. Each one I solved revealed the next.

When I started, execution was the constraint — I was the one typing. When agents started writing real code, the bottleneck moved one stage upstream to execution planning: which agent, which capabilities, what context, what worktree. So I built that out. Then reviews and quality gates were the constraint, because I couldn’t trust output I hadn’t inspected. So I built reviewer agents and audit scorecards. Then close out — merging worktrees, cleaning up sessions, advancing the next task — was the friction. So I built that into Skadi.

That cleared the back half of the line.

Now the bottleneck lives upstream: task creation, planning, and spec. Generating well-formed tasks from a plan. Structuring a plan that actually decomposes. Writing a spec precise enough that the rest of the line can do its job. The thing I have to think hardest about isn’t writing code anymore. It’s articulating what to build clearly enough that the system can execute it.

What I didn’t expect was the direction. Every time I solved a downstream stage, the bottleneck moved upstream — toward intent, not away from it. The frontier of the work keeps walking toward the part of the job only I can do: deciding what’s worth building.

That’s the actual payoff. Not speed. Not magic. A relocation of where the hard thinking lives — and it keeps moving toward the most human part of the work.

This is what the productivity content online doesn’t capture, because most of it is selling instant gratification. The real payoff is months out, and it isn’t faster typing. It’s a different question to wake up thinking about.

What scaling looks like

Today my Valdr workspace has 183 capabilities and 32 agents. That sounds like a lot. It is a lot. It didn’t happen all at once — it happened the way scaffolding always happens, one frustration at a time. A correction I made twice became a capability. An orchestration step I did manually three times became a workflow.

The number isn’t a goal. It’s a side effect of refusing to do the same thing twice.

Day-to-day I lean on a handful of agents — Skadi for sprints, a couple of executor/reviewer pairs for the actual work. The long tail of specialists matters because when I need an auditor or a planner, it’s already there, already loaded with the right capabilities. I also keep a polyglot test project (valdr-lab) with apps in TypeScript, Go, Java, Python, and Rust — most of my hardest bugs surface there before they can surface for anyone else.

But the inventory isn’t the point. The point is I’m not the composition engine for any of it.

What I’d skip if I started over

I spent too much time building features for the free tier.

I wanted Valdr to have a useful free-tier experience — something a solo dev could pick up without paying — so I built a lot of UI-first features before the MCP path was ready. Raider still matters: it lets people explore the control plane, understand the primitives, and see how plans, tasks, reviews, agents, and capabilities fit together. But the compounding value starts when agents can drive that system directly through MCP. Vanguard and Sovereign are where Valdr stops being a dashboard you operate by hand and becomes infrastructure your agents can use.

If I started over, I’d ship MCP earlier and worry about polish later. The compounding value only shows up when agents are calling Valdr, not when humans are clicking through it.

The convergence test

I built a parallel system for another project using just local agent skills — no Valdr, no MCP, just well-structured skill files.

It works.

That’s the honest answer. You can build a workflow with skills alone. For a focused, linear flow, it’s perfectly serviceable.

The wall I hit was composition.

Skills are rigid. You can build a skill that does a thing, but stringing multiple skills together into different workflows — where capability A shows up in workflow X and workflow Y, doing slightly different things in different contexts — is hard. You either duplicate skills or break each one into atomic pieces and re-stitch them. Either way, the composability tax is paid by you, every time.

Valdr’s capabilities compose. You write a capability once, attach it to multiple agents, and it loads on demand based on intent. The same capability can show up in three workflows without copy-paste.

The folders broke me because I was the composition engine. Skills work, but they ask you to be the composition engine in a different way. Capabilities are the first time I haven’t been.

The primitives are inevitable

Every serious AI workflow eventually converges on the same problems: persistent context, reusable behavior, runtime orchestration, and reviewable execution. You don’t get to skip these. You only get to choose whether you encounter them as features in a system, or as load-bearing pieces of your own brain.

If you’re using CLI agents or IDE copilots seriously, you’re already building this. You have a tool-specific config directory or a folder of skills or an AGENTS.md you keep editing. You have prompts you paste, conventions you re-explain, scaffolding that grows.

You won’t end up with Valdr. You’ll end up with the parts Valdr is made of — agents, capabilities, prompts, workflows, hooks — scattered across skill files, AGENTS.md, prompt directories, and hand-rolled scripts. The primitives are inevitable. The only question is whether they cohere into a system you can compose, or accrete as config you have to maintain.

I built mine over months. I’d suggest skipping that part.

The folders aren’t the problem. Being the integration layer is.

Valdr is local-first, MCP-native, and built for engineers who are tired of being the integration layer. Get started →