4 posts tagged with "ai-agents"

Spec-driven development usually arrives as a framework: a sequence of phases, a command for each, templates, a governing document, and the assumption that one developer drives one agent through one repository. Seen that way, it looks like a heavy process to adopt – and for a team with its own tracker, its own roles, and dozens of services, adopting it that way is heavy and often unnecessary.

Under the packaging, SDD is a handful of ideas. My team runs it without a framework. I designed the process around those core ideas; the team adopted it, and five months later it is simply how we work – a team lead, two engineers, a PO/BA and two QA engineers, responsible for 80+ microservices. Agents write every document; people decide, direct each stage, and take responsibility for the result. Two things made it simple: an AI-native meta-repo, where the agent sees the whole system at once, and a triage step that keeps most work away from specifications altogether.

It isn't free. A home-grown process has no community or upgrade path behind it. It fits one team's context rather than every team's, and it leans on the workspace – without one, it becomes considerably heavier.

This piece is the argument, with my team's version as the example. The mechanism, decision by decision, is in RA-005.

The most expensive thing my agent can do is ask its smartest model a trivial question.

That sounds backwards – trivial questions are supposed to be cheap. A two-line summary, a yes/no judgement, a bit of text cleanup: milliseconds of honest work for a competent model. But Azek runs on one machine, and on one machine the flagship model's attention is the scarcest resource in the system. Every small job it handles personally gets paid for twice: once in the GPU it occupies, and once in a currency most people never see billed.

So Azek – the self-hosted agent from the first post – runs two models side by side, on purpose. The big one talks to me. The small one does everything else. This post is about the second lane: why it exists, what drives on it, and why the split turned out to be one of the best decisions in the whole project.

Last month my AI agent spent eight minutes turning one email into a calendar event. Five of those minutes were pure waste – the model fumbling with tool parameters, failing validation, retrying, fumbling again. I sat there watching tool_input_invalid errors scroll past, produced by software I own completely, running on hardware I paid for, doing a task any cloud assistant finishes before you've put the phone down.

I'd do it all again tomorrow. This post is about why – and it's the opening move of a series about what it actually takes. (Part 2 looks at why a second, simpler model runs beside the primary.)

Because the obvious question deserves a straight answer. It's 2026. Capable AI agents are a commodity: sign up, connect Gmail, press "allow," done. Why would anyone build one from scratch and insist it runs on a laptop?

Engineering teams frequently misconfigure AI coding agents (Copilot, Kiro, Claude, Codex, and others) by relying exclusively on on-demand skills — callable procedures and tool descriptions defined in an agent's tool registry (such as those conforming to the agentskills.io standard) — to enforce strict project rules. This approach fundamentally misunderstands the architecture of foundation models. When compliance mandates are embedded within dynamic tool descriptions, they are subject to conditional execution and instructional distraction. To prevent agents from silently violating security baselines and tooling mandates, organisations must implement a dual-layer architecture: static steerings for immutable boundaries and dynamic skills for isolated execution.