Capabilities: The Control Plane Behind the Agents

A vanilla Node server, four agent consumers, and the rules that keep capabilities safe: least privilege, one builder, and receipts for everything.

An agent that can’t touch your systems is just a chatbot with confidence. This piece distills three working recordings and a stack of 2026 research into a single pattern: one deliberately boring Node server standing between your agents and everything they act on — owning secrets, policy, and receipts. Here is how it is built, the rules that run it, and why the model turned out to be the easy part.

One Node API server between agents and everything they touch.

An agent without capabilities can reason but cannot act. The moment it needs Gmail, LinkedIn, search, files, or money movement, the model stops being the system — the capability layer becomes the system. This is the story of one such layer: a vanilla Node server, four agent consumers, and the rules that keep it safe.

1. Capabilities were the bottleneck all along

It started with someone else's engineering notes — the OpenAI harness post about building an internal application with agents — where the author said the thing the team spent most of its time on was creating capabilities:

“So, we're talking about capabilities. I bumped into an article the other day that was from the GPT team and talked about how they were building their internal application. One thing jumped out at me is the author talked about the thing that they spent most of their time on and the project was creating capabilities and that to me suddenly became kind of a mantra for my own work and realizing I think this concept really opens the door for how you power up your agents in a safe and a scalable way.”— Govind Davis

That framing is worth sitting with, because the OpenAI post is really a capabilities story wearing a code-generation costume. Yes, the headline numbers are the ones everyone quotes — about a million lines shipped with zero hand-written code, roughly 1,500 pull requests, three engineers running at 3.5 PRs per engineer per day, built in about a tenth of the time hand-writing would have taken. But read past the numbers and the work that consumed the team wasn't prompting. It was environment-building: making the application bootable per git worktree so an agent could drive its own instance, wiring the Chrome DevTools Protocol into the agent runtime so it could see its own UI, exposing logs and metrics so prompts like “no span exceeds two seconds” became tractable. Humans steered; agents executed; and the steering wheel turned out to be made of capabilities — tools, feedback loops, and legibility — not words in a chat box.

WEBVTT

00:00.000 --> 00:49.080
So, we're talking about capabilities. I bumped into an article the other day that was from the GPT team and talked about how they were building their internal application. One thing jumped out at me is the author talked about the thing that they spent most of their time on and the project was creating capabilities and that to me suddenly became kind of a mantra for my own work and realizing I think this concept really opens the door for how you power up your agents in a safe and a scalable way. So, what are we talking about here, right?

00:49.080 --> 01:28.880
So, you know, everybody, you know, you're using building agents, right? Or you're, you know, you want to, you know, you're vibe coding your own like super powered agents, right? And, you know, you can go and use these, you know, vibe code tools, you know, code X or, you know, cloud code and what have they run on your local machine or you can run them in a sandbox and you can kind of manage, constrain them in the sandbox. But, you know, what happens is eventually you start wanting to have more purpose built agents, right? I want an agent that just does certain things and or and or I want to

01:28.880 --> 02:09.520
build an application that the agent can operate and that application needs capabilities and the way to do that in a really straightforward way is build, you know, a capability server, right? So, it's one server, you can obviously build multiple capability servers or scale this up or do whatever. But the simplest way is is create a capability server. It's basically just a bunch of APIs with consumers and those APIs can do things they can connect to Google. They can connect to, you know, whatever services make sense for your

02:09.520 --> 02:45.600
workflows in your business and that way you can control which agent has access. You don't ever need to provide any secrets or, you know, keys to your agents, right? This server, you know, can connect to whatever secret store you have and has policies, you know, that can be simple or complicated and, you know, and are advanced and just allow those agents to go and do the things that they need to do. So, examples of this, I mentioned Gmail, right? I want to be able to access my Gmail and organize any Gmail. That's one of the jobs that I run. I love it.

02:45.600 --> 03:18.520
It just puts things every, you know, every few every hour or whatever into like some logical boxes for me. So, I only pay attention to the stuff that I care about, right? Or, you know, it has some things to connect with LinkedIn or search capabilities, another one. You have to be really careful. Anything that you're paying for, you want to regulate it, right? I got a $60 brave search bill for doing nothing. It was just checking, you know, it was just running an API call to see if it was working and I wasn't, you know, I didn't build it right. So, this is the key, right?

03:18.520 --> 04:00.120
It's agent run time, whatever you use, you know, has access in a secure, defined way to your capability server that enables whatever capabilities, integration, endpoints, functions, you want it to be able to do. So, you know, what are the guardrails here, right? You know, only give things what they need. So, usually what I try to do is I'll say, hey, I want to build X, go look at the capabilities we have. Tell me what you need, you know, that's there. So, we can enable that. And number two, tell me if there's anything missing and then we'll build that, right?

04:00.120 --> 04:37.880
And I actually have one agent, which is my DevMaster agent, that is explicitly responsible for building and enabling these capabilities. Nobody else can do it. No other, nothing else can do it. So, that way I can control everything. And what's the outcome, right? You can build applications that essentially can, you know, use and leverage these capabilities. The agents can use those applications. And this is how you can give yourself a, you know, an agentic superpower without breaking your back and try to, you know, without creating a huge mess, essentially.

04:37.880 --> 04:46.960
This, you know, this took me many, many hours and bang my head against the wall to kind of, to, to come clear on this and hopefully it provides some value for your learning.

2. The bottleneck moved — and it was measured

One number from the independent research cuts through all of it. Marmelab's September 2026 audit — 246 repositories, 57 publications — reports the only properly measured result in the young discipline: the same model run through 8 different harnesses on the same 25 tasks went from a 68% to an 88% success rate. Same model, same tools, same provider. Twenty points of capability that lived entirely outside the model weights.

The field has converged on a sentence for this. Thoughtworks' Birgitta Böckeler, writing for Martin Fowler's site, put it as Agent = Model + Harness. The model reasons; everything else — tools, memory, state, verification — is engineering. Anthropic's own long-running-agent work shows what happens without it: agents that one-shot everything and run out of context mid-implementation, that declare victory on partial work without verifying anything, that rot as tool output fills the window, hallucinate tool calls, and lose everything on a restart. Firecrawl's harness guide adds the quiet corollary teams discover late: memory portability. If your agent's accumulated knowledge lives inside a closed harness you don't control, switching systems means starting from zero. Build for portability from the start — own the layer where capabilities and memory live.

The field reports read like dispatches from the same war. Stripe's “Minions” ship around 1,300 AI pull requests a week, roughly 70% merging with no human rework — and Stripe's companion lesson is the one to underline: passive documentation gets ignored by agents, so you need mechanisms, not instructions. GitHub's writeup on multi-agent failure lands in the same place — typed schemas as the answer — and Addy Osmani's experiments show separating generation from evaluation into distinct agents beats self-evaluation. Every one of these is a capability story: the artifact that made the agent reliable was never a better prompt.

3. The tool layer is designed, not prompted

“A tool is a defined capability that allows a language model to execute operations and retrieve information from external systems.” That sentence, from Firecrawl's January 2026 agent-tools guide, is the whole thesis in one line — and the guide's nine categories read like an inventory of what a capability server grows into: web search and extraction, RAG retrieval, code execution, databases, communication, browser use, observability, memory, and security policy. Then comes the part most teams skip: design rules. Unambiguous parameter names (models guess formats wrong about 30% of the time on vague ones). Error messages that teach the fix instead of dumping a code. Idempotency, because agents will retry. Rate limits that explain themselves. Token-efficient responses, because every verbose payload compounds across every turn of every loop.

None of that is prompting. It is API design with a non-deterministic client — which is exactly why the evaluation discipline matters: tool-selection accuracy, latency distributions, cost per task, and categorized failure modes. Anthropic's research on writing tools for agents found even small refinements to tool descriptions yield dramatic improvements. The capability server in these videos is that discipline running in miniature: every connector shaped so the agent can use it reliably, every failure cheap enough to learn from.

“So, this week we're talking about capabilities and for me, this is where the rubber hits the road. This is an output from literally vanilla, most basic node server.”— Govind Davis

4. One server, many consumers

Here is the architecture on camera, and it is deliberately boring: a vanilla Node server, running as a Docker instance, exposing every integration as an API endpoint with named consumers — four agents plus Pulse, a monitoring job:

“The basic idea here is you have consumers. So, you know, I've got four different sort of agents that access this right now, plus like a pulse, which is just a monitoring job.”— Govind Davis

Each capability is a connector — Apollo, LinkedIn, Gmail, TinyFish search added recently, external reasoning, bulk mail sending — and then it gets enabled for a particular agent, which goes to work. The server loads secrets when it needs them; the agent never sees a token, only its rights as a consumer. That single sentence — rights as a consumer, never the keys — is doing more security work than most enterprise permission pages.

WEBVTT

00:00.000 --> 00:49.080
So, this week we're talking about capabilities and for me, this is where the rubber hits the road. This is an output from literally vanilla, most basic node server. There's a lot of stuff out there, you know, MCP and all these different ways to power up your agents and for me, this is the simple vibe code way to do this. It's super easy and it's just super powerful and it also gives you the kind of control and security and observability, visibility that you're going to want to have. The idea here is, you know, I run this as a Docker instance.

00:46.200 --> 01:28.280
It's a basic vanilla server, node server and I honestly, I just created this little visibility UI just to show, to record this. I really don't look at it all that much. My agents use this all the time. They tell me if there's something there they need. If they need, you know, Friday, need something else. If ghosts need something else. And the basic idea here is you have consumers. So, you know, I've got four different sort of agents that access this right now, plus like a pulse, which is just a monitoring job. So, you can see these here and these are the consumers capabilities are, you know,

01:28.280 --> 02:08.360
many, right? So, they're all basically API endpoints, right? So, each one of those is just something that is like a connector to generally it's going to be some other kind of service, right? Apollo, LinkedIn, Gmail, just recently I added, you know, tiny fish. There's a bunch of other things here for like external reasoning, bulk sending on mail, trap, you know, everything you can imagine gets created as a capability. And then after that, you enable it for a particular agent and they can go to work. The one important thing to think about this is it's also really able to protect your secrets.

02:08.360 --> 02:45.960
What you don't want to do is give your secrets to your agents. So, you don't want to, you want to keep your secrets separate. And so, what my capability server does is it loads in the secrets when it needs them and it allows the agent to connect to the capability and never actually see whatever that, you know, API token is, that, you know, access code. So, all of my agents have access to whatever capabilities they need, but they never know that they don't have the keys. They only have, you know, the rights as a consumer to these capabilities. This is the straightforward way to do this.

02:45.960 --> 03:01.800
It's easy for any kind of agenting, you know, coding tool to set up and build this kind of server and it gives you control, it gives you power and control without the kind of risks that happen if you just, you know, give your agents access to everything.

5. The rules that run it

Distilled from all three recordings, every line said on camera. Least privilege, always: only give things what they need. Let the agent spec the gap: “Go look at the capabilities we have. Tell me what you need… tell me if there's anything missing and then we'll build that.” One builder: the DevMaster agent is explicitly responsible for building and enabling capabilities — “Nobody else can do it. No other, nothing else can do it. So, that way I can control everything.” Regulate anything metered: a $60 Brave Search bill “for doing nothing” — a health check left running — which is why paid capabilities get caps. Run it where it can't leak: secrets load server-side at call time; the server itself runs as a Docker instance.

The DevMaster rule deserves a pause, because it scales beyond one person. What it really is: a single accountable owner for the capability surface, with every other agent as a consumer. Small teams implement it as a person plus a review rule; larger ones as a platform team plus a registry. Anthropic's Agent Skills point the same direction from the top down — modular, discoverable capability packages with team sharing — and Google's 2026 agent workspace added shared company skill registries. The pattern rhymes at every scale: capabilities get built once, owned clearly, and consumed widely.

And the pattern is still spreading. Google's 2026 agent workspace lets teams publish custom skills to a shared company registry; the self-improvement literature — reflection loops, skill libraries, tool-creation — is converging on the same idea from the research side: agents that get more capable over time by accumulating owned, governed capabilities rather than longer prompts. Whether the owner is a DevMaster agent, a platform team, or a registry with review rules, the shape holds.

6. API vs MCP, honestly

The videos leave room for MCP without making it load-bearing: “There's a lot of stuff out there, you know, MCP and all these different ways to power up your agents and for me, this is the simple vibe code way to do this.” The honest industry picture, from Firecrawl's 2026 API guide, lists five integration patterns — direct REST, tool/function calling, MCP gateways, unified platforms, agent-to-agent — and notes production systems usually combine two or three. Production fails on the same five things regardless of pattern: auth, rate limits, API drift, injection in returned content, and token cost. The position this article takes, matching the stub: MCP is one adapter for discovery and transport. It is not the security model. Auth, policy, validation, secrets, audit, and cost control live in the capability server no matter which protocol the agent speaks.

The security literature backs the caution. Between January and February 2026, researchers filed 30+ CVEs against MCP servers, clients, and infrastructure — including a 9.6-severity RCE in a widely-used MCP proxy present in over 437,000 environments — alongside tool-poisoning demonstrations, rug-pull approval decay, session weaknesses, supply-chain compromises, and roughly 7,000 internet-exposed MCP servers, about half with no authentication at all. Cloudflare's enterprise reference architecture answers with three planes — development, deployment pipeline, production — and one blunt assumption: treat AI-generated code as untrusted, and enforce protection at the platform layer. The capability server in these videos is that platform layer at solo scale: contracts, allowlists, approvals, audit.

7. Docker is where it lives

The shortest recording is the most personal — an honest Docker journey (early fear of containers, walked away, came back, never left) landing on the same thesis: Docker is where the capabilities live. Named on camera: PDF printing for studio content, video tooling, content-production tools, and the capability server itself:

“It gives me the ability to control the capabilities so that I'm not letting my agents get out of control and power up and let them connect to all kinds of different things in orchestrated ways.”— Govind Davis

Note the verb: control, not connect. Connection was never the hard part. The 2026 Stack Overflow survey found 83% of developers already use AI tools; connection is abundant. What's scarce is governed connection — which agent, which capability, which scope, at what cost, with what receipt. The survey's trust numbers tell the same story from the other side: developers trust AI output when they can verify it, and verification is a capability — logs, diffs, test runs, cost ledgers — not a feeling.

WEBVTT

00:00.000 --> 00:54.720
When I first started vibe coding, I jumped into Docker early and I really honestly, I got afraid of it early on and I moved away because I was afraid to have a couple of even like a couple of containers or I was like, oh my gosh, it's too many containers like what is all this? Then I had all kinds of challenges and came back to Docker and since then, it's been amazing and I have some other recordings about this. What I'm here today to really focus on, it's really about capabilities and that is what Docker does for me. By creating capabilities and superpowering my platform,

00:54.720 --> 01:40.560
that allows me to power up my agent. So there's a bunch of different capabilities here. I have PDF printing, for example. That's a super important one, right? Like being able to consistently produce the PDF output for the studio content is super powerful. I have video content, I have content production tools, and most importantly, my capabilities server. So this is actually just a super simple node server that has a bunch of APIs and it allows me to connect and regulate which of my agents can connect to those APIs and what they can do. It's hyper powerful,

01:40.560 --> 01:53.400
it gives me the ability to control the capabilities so that I'm not letting my agents get out of control and power up and let them connect to all kinds of different things in orchestrated ways.

8. Applications carry workflows

Every capability in this piece carries a receipt — who called it, with what scope, at what cost, to what result — which is what turns a clever demo into something a business can run on. The payoff line:

“You can build applications that use and leverage these capabilities. The agents can use those applications. And this is how you can give yourself an agentic superpower without breaking your back — without creating a huge mess.”— Govind Davis

It took many hours of head-banging to get clear on this. That labor — the rules, the server, the receipts — is the product. AI is not a chat window at the end of the desk; it is a superpower at the fingertips, but only behind a control plane. The model is the easy part. Capabilities are the work.

Sources

Every number and quote in this article traces to one of these sources, checked against live pages on October 21, 2026.