Two things landed in my feed the same week, from completely different corners of the internet. Telos, Daniel Miessler’s open-source framework for writing down an entity’s mission, goals, and strategies as a structured file — and an O’Reilly Radar piece by Markus Eisele arguing that the real skill in agentic development isn’t writing code faster, it’s deciding how much specification a piece of work actually needs.
They are the same insight at two different altitudes. One is about specifying a person or a company. The other is about specifying a feature. Both are about the same emerging bottleneck: once an agent can produce plausible output in seconds, the thing you’re short on is no longer implementation — it’s a clear enough statement of intent to know whether that output is correct.
The Problem Isn’t Speed Anymore
Eisele’s framing is the one that stuck with me: “When code gets cheap, the hard part is deciding what ‘correct’ means and building a reliable way to check it.” Vague requirements used to fail slowly — a developer would ask clarifying questions, a ticket would sit in refinement, someone would eventually push back. Agents don’t do that by default. A vague prompt doesn’t stall, it turns into a working-looking system in minutes, and now you’re reviewing an artifact instead of a requirement. He calls this vague requirements running into machine speed, and it’s a good description of a failure mode I’ve watched happen more than once: the code runs, the demo works, and it’s still the wrong thing.
Telos is a response to the same problem, aimed one layer up. If an AI agent is going to act on your behalf — triaging your inbox, drafting your content calendar, prioritizing your backlog — it needs a durable, structured statement of what you’re actually trying to do, not a one-off prompt reconstructed from memory every session. A Telos Context File captures mission, current objectives, known problems, and the strategies in play, in one place an agent (or a new team member) can read cold.
Calibrating Spec to the Work
The useful part of Eisele’s piece isn’t “write more specs” — it’s that the right amount of spec depends on what kind of work you’re doing:
- Small, bounded tasks — structured intent is enough: a goal, a couple of examples, acceptance criteria. Anything heavier is wasted ceremony.
- Deterministic work (CRUD, APIs, anything with an obviously correct shape) — spec harder here, because executable tests pay for themselves immediately. This is where “validate the spec before you scale the implementation” matters most.
- Exploratory work — spec less. Over-specifying exploration just encodes your first guess as a constraint. Define the boundaries you actually care about (cost, safety, data access) and let the agent explore inside them.
- Multi-agent systems — spec hardest at the seams. Every handoff between agents needs a contract as strong as an API contract between services, because there’s no human in the loop to notice a silent mismatch.
My Take: This Is Now Infrastructure Work
I’ve been building AI platforms long enough to recognize this pattern — it’s the same lesson platform engineering learned about API contracts between microservices, just one layer up the stack. A Telos-style file at the org level is the north star that keeps a team’s agents pointed at the right problem. A tight spec with executable tests at a service boundary is the “strong contract” that keeps a multi-agent pipeline from silently drifting.
If you’re operating AI infrastructure — not just calling a model API, but running agents that make decisions across a system — write both down. The org-level intent (a Telos-style file, or your own version of one) tells agents why they exist. The per-task spec tells them what correct looks like this time. Skip either one and you get a system that’s technically running and still not doing what you meant.
A practical starting point: pick one recurring agentic task on your team, write its acceptance criteria as an executable check before the next iteration, and see how much review time it saves. That’s the whole argument in one experiment.
Related Reading
- Karpathy’s CLAUDE.md: 4 Rules That Fix LLM Coding
- AI Coding Agents and Platform Engineering
- Context Architecture for AI Agents
- Agentic AI on Kubernetes for the Enterprise
Go Deeper
If specifying intent for AI agents is becoming part of your job, the AI Platform Engineer Bootcamp treats it as one — you’ll write architecture specs, acceptance criteria, and operational runbooks for a real deployment, not just prompts.
- 🎯 AI Platform Engineer Bootcamp — four weeks from infrastructure experience to AI-platform capability
- 📋 AI Platform Engineer Readiness Scorecard — free, 10 minutes, no signup
