| name | agent-native-architecture |
| description | Build applications where agents are first-class citizens. Use this skill when designing autonomous agents, creating MCP tools, implementing self-modifying systems, or building apps where features are outcomes achieved by agents operating in a loop. |
| model | opus |
Agent-Native Architecture
Software agents work reliably now. A really good coding agent is a really good general-purpose agent — the same loop that refactors a codebase can organize files, manage reading lists, or automate workflows. Features aren't code you write — they're outcomes an agent achieves with tools, operating in a loop until the outcome is reached.
Core Principles (summary)
Full explanation in references/core-principles.md.
- Parity — Every UI action has an agent capability to achieve the same outcome.
- Granularity — Atomic primitives. Features emerge from prompts + agent judgment.
- Composability — New features = new prompts, no new code.
- Emergent Capability — Agent solves problems you didn't explicitly design for.
- Improvement Over Time — Accumulated context + prompt refinement → app gets better without shipping code.
What aspect do you need help with?
- Design architecture — Plan an agent-native system from scratch
- Files & workspace — Files as universal interface, shared workspace
- Tool design — Primitives, dynamic capability discovery, CRUD
- Domain tools — When to graduate from primitives to domain tools
- Execution patterns — Completion signals, partial completion, context limits
- System prompts — Features in prose, judgment criteria
- Context injection — Runtime app state into agent prompts
- Action parity — Ensure full capability mapping
- Self-modification — Safe evolution
- Product design — Progressive disclosure, latent demand, approval
- Mobile — iOS storage, background, checkpoint/resume
- Testing — Outcome and parity tests
- Refactoring — Make existing code agent-native
Wait for response.
Routing
| Response | Read |
|---|
| 1, design, architecture, plan | architecture-patterns.md → apply checklist below |
| 2, files, workspace, filesystem | files-universal-interface.md, shared-workspace-architecture.md |
| 3, tool, mcp, primitive, crud | mcp-tool-design.md |
| 4, domain tool, when to add | from-primitives-to-domain-tools.md |
| 5, execution, completion, loop | agent-execution-patterns.md |
| 6, prompt, system prompt, behavior | system-prompt-design.md |
| 7, context, inject, runtime, dynamic | dynamic-context-injection.md |
| 8, parity, ui action, capability map | action-parity-discipline.md |
| 9, self-modify, evolve, git | self-modification.md |
| 10, product, progressive, approval, latent demand | product-implications.md |
| 11, mobile, ios, android, background, checkpoint | mobile-patterns.md |
| 12, test, testing, verify, validate | agent-native-testing.md |
| 13, review, refactor, existing | refactoring-to-prompt-native.md |
After reading the reference, apply those patterns to the user's specific context.
Architecture Checklist
Verify before implementation.
Core principles
Tool design
Files & workspace
Agent execution
Context injection
UI integration
Mobile (if applicable)
Quick Start
1. Atomic tools:
const tools = [
tool("read_file", "Read any file", { path: z.string() }, ...),
tool("write_file", "Write any file", { path: z.string(), content: z.string() }, ...),
tool("list_files", "List directory", { path: z.string() }, ...),
tool("complete_task", "Signal task completion", { summary: z.string() }, ...),
];
2. Behavior in system prompt:
## Your Responsibilities
When asked to organize content:
1. Read existing files to understand structure
2. Analyze what organization makes sense
3. Create/move files using your tools
4. Use your judgment about layout and formatting
5. Call complete_task when done
You decide the structure. Make it good.
3. Loop:
const result = await agent.run({
prompt: userMessage,
tools,
systemPrompt,
});
Reference Files
Core patterns
Disciplines
Platform-specific
Full treatments
Success Criteria
Architecture
Implementation
Product
The ultimate test
Describe a domain-relevant outcome you didn't build a specific feature for. Can the agent accomplish it in a loop? If yes → agent-native. If "I don't have a feature for that" → architecture is still too constrained.