Emergent Capability: Agents Do What You Didn’t Design For
The Idea
When tools are atomic and parity is complete, the agent can accomplish things you never explicitly designed. A user asks: “Cross-reference my meeting notes with my task list and tell me what I’ve committed to but haven’t scheduled.” You didn’t build a commitment tracker. But if the agent can read notes and tasks, it can compose them into the outcome.
The flywheel that makes this self-reinforcing:
- Build with atomic tools and parity.
- Users ask for things you didn’t anticipate.
- Agent composes tools to accomplish them — or fails, revealing a gap.
- You observe patterns in what’s being requested.
- Add domain tools or prompts to make common patterns efficient.
- Repeat.
Why It Matters
Emergent capability changes how you build products. You’re not trying to imagine every feature upfront. You’re creating a capable foundation and learning from what emerges. This reveals latent demand without surveys, interviews, or guesswork — the requests themselves are the signal.
The Test
Can the agent handle open-ended requests in your domain that you didn’t explicitly anticipate? If yes, you’ve earned emergence. If no, your tools are too coarse, your parity is incomplete, or both.
Related
- Composability - New Features Through New Prompts — emergence is what composability looks like in production, with real users
- Latent Demand Discovery Through Agent Usage — emergent agent usage is the cleanest signal of latent demand
- Parity - Agents Need Tools for Everything the UI Can Do — without parity, the agent runs out of moves before it can compose
- Granularity - Tools Are Atomic Primitives, Features Are Outcomes — atomic granularity is what makes composition possible
- Progressive Disclosure - Simple to Start, Endlessly Powerful — emergence is what gives power users room to grow