ai-agents

The useful unit in agent systems is not a better instruction. It is a tested capability package: judgment, code, checks, routing, and boundaries.

Model revenue is not customer return. The economic and risk unit is the harness that turns model output into accountable work.

Once model companies supply the generic agent harness, the valuable work moves into workflow design, human intervention, domain data, and the definition of good work.

Enterprise AI stops being a chatbot when the operating procedure becomes the thing the system can execute, inspect, and improve.

If a product wants agents as real users, first-run setup has to be an executable workflow, not a human signup ceremony wrapped in documentation.

Assigning roles to AI agents can look like governance. It only becomes useful when the role has a loss function, an evidence boundary, and an output contract.

Agent governance cannot stop at model behavior. Once AI systems use tools, the governed object is the whole workflow.

An agent is not autonomous because it can try a task. It is autonomous when the system can tell whether the task worked.

Agent-native apps do not become trustworthy when an agent can call tools. They become trustworthy when the app can prove those tools worked.

In a concurrent agent system, verifying the latest artefact is not verification. It is a scheduling bet.

Nous Research shipped an open-source personal agent that does most of what my bespoke system does. Here is what they got right, what they traded away, and what I stole.

Self-improving AI agents sound like the dream. But auto-generated knowledge is cheap, and cheap knowledge plateaus. The agents that compound are the ones someone tends.

What Browser Harness gets right isn't the absence of structure — it's structure that emerges from use.

I designed an elegant framework install for my personal AI system. Then I listed the hard problems and shipped a three-hour cleanup instead.

I renamed one concept across 130 files. The pain crystallized into a tool that will do the next rename in minutes.

The tool/skill distinction isn't a property of the capability. It's a property of the context it operates in.

The line between tool and skill is whether you can write the test before seeing the result.

The line between tool and skill isn't a property of the task. It's a property of how well you understand the task.

Every AI skill should be trying to make itself unnecessary. The ones that survive are the ones that haven't been understood yet.

When the transformation is predictable, the LLM is just a runtime. A cheaper, more flexible runtime than custom code.

I ran an autonomous agent loop overnight — 43 waves, ~270 dispatches, ~250 vault files produced. Here's what I learned about building systems that work while you sleep.

In AI agent systems, execution commoditizes. Research commoditizes. Coordination commoditizes. Taste — the ability to forecast what will matter — is the bottleneck that doesn't automate away.

Your agent system shouldn't stop when the task list is empty. The real bottleneck isn't execution — it's discovering what's worth doing next.

The temptation in agent systems is to make everything a prompt. But most of the work is deterministic — and deterministic work deserves code, not suggestions.

When you can run 60 agents overnight, knowing what to build matters more than building it.

We cut from 181 skills to 35 and added a 15-row routing table. Behavior improved across the board. The lesson: meta-skills compound, tool wrappers just add.

With 1M context windows, token savings are rounding error. The real metric is P(right tool | user intent) — does your agent reach for the right tool at the right moment?

In AI agent systems, use the most reliable trigger mechanism that fits — most builders default to skills for everything, which is using the weakest mechanism as the default.

Skills and MCP servers aren't competitors. They're different stages of the same lifecycle. Build the procedure as a skill first. Graduate the tool parts to MCP when they stabilize.

Agent knowledge systems have three fundamental paradigms: static context, dynamic tools, and retrieval. Most stop at two. The third is the biggest unexploited opportunity.