LANDMARK · 8 MIN · BUILD
Writing an agent specification
After this landmark, you can write an agent specification that captures scope, permissions, checkpoints, and failure handling before implementation starts.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
An agent specification is the single document that should exist before an agentic system is built; an IT-ticket triage agent, a refund-approval agent, a scheduling assistant: what the agent’s task is and isn’t (scope), what tools and data it can access (permissions), where a human must approve before an action proceeds (checkpoints), how failures are detected and contained (monitoring and kill switch), and what ‘done’ means for evaluation.
Every landmark in this ring (framing, tool contracts, permission scopes, checkpoints, evaluation, monitoring, incident response) is a section of this document. Writing it forces the team to make these decisions deliberately, together, before implementation, rather than discovering the gaps one incident at a time.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
What this looks like for you
Not your layer directly, but a well-specified agent is the difference between an assistant that clearly knows its job and boundaries, and one that seems to improvise its scope as it goes.
MAKE A DECISION
A team is about to start building an agent that manages internal IT tickets; reading requests, taking some actions automatically. What should happen first?
CARRY THISSketch a one-page agent specification (scope, permissions, checkpoints, evaluation, failure handling) for an agent you build, use, or are considering adopting.