Intent is built on a four-step loop that turns everyday problems into structured, observable work.
The Intent loop (Layer 2: Transformation OS) operates over a compiled knowledge base (Layer 1) and produces running software specifications (Layer 3). See Architecture for the three-layer model.
1. Notice
Notice is where it starts. You're working, building, thinking—and you spot something. A pattern. A pain. A gap between what is and what could be.
Noticing is not the same as complaining. It's specific observation:
- "I write the same email structure three times a week"
- "My team spends 30 minutes in meetings repeating context from last week"
- "I have to manually copy data between these two systems"
Once you notice something, you've found a spec waiting to be written.
2. Spec
A spec is intent made explicit. It's the bridge between "something feels wrong" and "here's what we're building." Good specs are:
- Specific: Not "improve communication" but "write a template for standup updates that takes 5 minutes and includes: what I shipped, what I'm blocked on, what I'm starting next"
- Measurable: "We should get feedback within 24 hours" or "The automation should save 2 hours per week"
- Actionable: The spec tells the person (or AI) executing it exactly what to build
Specs unlock AI. A vague request gets a vague response. A spec—a clear problem statement with constraints—gets reliable execution.
The transition from Notice to Spec is formalized through the spec-shaping protocol—a four-persona interrogation where each persona (△ Architect, ◇ Product Leader, ○ Quality Advocate, ◉ Agent) queries the compiled knowledge base to produce an agent-ready specification. See the Agents page for the full protocol.
3. Execute
Execution is where the spec becomes real. It might be:
- Building a script or workflow
- Designing a new process
- Creating a template or tool
- Coding a feature
With a good spec, execution becomes reliable and traceable. You hand the spec to an AI agent, and it delivers. You can audit what it did. You can iterate if needed.
4. Observe
Observe closes the loop. After executing, you watch:
- Did it work?
- Was it faster, better, simpler?
- What broke?
- What would we change next time?
Observation feeds back into notice. You see a gap. You write a spec. You execute. You observe. Then you do it again.
Why This Loop Works with AI
Traditional software development has spec→build→test→ship. Intent adds observe to close the loop and notice to start it. This is powerful with AI because:
- AI executes specs reliably: Give a good spec to Claude, it builds correctly. No guessing, no ambiguity.
- Observation is traceable: Every execution leaves traces—commits, logs, outputs. These become signals for the next loop.
- Notice drives urgency: You notice something and immediately spec it. No prioritization committee, no backlog grooming. Just: notice → spec → execute → observe → repeat.
- Feedback is fast: You observe results within hours or days, not quarters. This creates tight feedback loops and rapid improvement.
In Practice
Here's what a notice→spec→execute→observe cycle looks like:
Notice: "I'm manually copying deployment info from Jira into Slack every Friday."
Spec: "Build a bot that runs every Friday at 4pm, queries Jira for all tickets closed in the past week, and posts a summary to #deployments with: ticket ID, title, assignee, completion date. Use the Friday Deployment template."
Execute: Hand that spec to Claude or another AI agent. It writes the bot. You run it. It works.
Observe: The first run posts to Slack. You notice it's missing one field. You update the spec. You execute again. Repeat until it's perfect. Now every Friday it runs automatically.
Two-Plane Architecture
Intent operates across two independent planes that interact through persistent artifacts.
Work Stream Plane
The work stream plane contains ephemeral flow entities that move through the notice→spec→execute→observe cycle:
- Signal: A noticed friction point or opportunity
- Intent: The framing of what needs to be addressed
- Atom: An execution envelope that references specs and contracts, containing the work and its outcomes
- Event: Observable facts about execution (success, failure, metrics)
- Trace: The recorded history of execution and observation
These entities flow through the system, grow, transform, and eventually complete. They're temporary by design—they exist to drive work.
Ownership Topology Plane
The ownership topology plane contains persistent structures that organize ongoing responsibility:
- Product: A coherent system or offering
- Capability: A bundle of skills, patterns, and tools
- Team: The people who own and evolve the product
These structures are stable and intentional. They define who is responsible for what and how work gets organized.
Bridging Artifacts
Two independent persistent artifacts bridge the two planes:
- Spec: A problem statement with constraints and success criteria. Specs are authored in the ownership plane but consumed by atoms in the work stream plane. A spec persists across multiple atoms—it defines the shape of work.
- Contract: An agreement about ownership, governance, and resource allocation. Contracts bind teams to products and capabilities. They persist independently and guide how work gets authorized and executed.
Atoms reference specs and contracts, but they don't contain them. This separation allows a single spec to drive multiple execution attempts and a single contract to govern multiple work streams.
Interactive Artifacts
Explore the Intent system through these interactive resources: