Agent-Native Applications
Agent-native applications are the idea that software can be architected with agents as first-class citizens and tools as atomic primitives. Features become outcomes described in prompts and achieved by an agent operating in a loop, rather than logic encoded in application code.
Details
The architecture rests on five principles. Parity requires that the agent can achieve anything the user can do through the UI, through tools or combinations of tools. Granularity means tools are atomic primitives rather than workflow bundles; judgment about what to do belongs in the agent's reasoning, not baked into tool implementations. Composability follows from atomic tools and parity: new features can be created by writing new prompts without code changes. Emergent capability arises when agents compose tools in ways the developer did not anticipate, revealing latent demand. Improvement over time comes from accumulated context (state persists across sessions via context files) and prompt refinement at developer and user levels, without shipping code.
Customer support agents illustrate a partial version of this pattern: schema-constrained business API tools serve as atomic primitives, and the agent loop handles edge cases and routing decisions rather than hard-coded branching logic. Skills extend this further: each skill is a prompt-based feature the agent runtime injects when relevant, enabling new capabilities without code changes.
Domain-specific tools emerge from observed usage patterns rather than upfront design: start with pure primitives (bash, file operations, basic storage), observe what the agent actually needs, and add domain tools deliberately for vocabulary anchoring, guardrails, or efficiency. Domain tools represent one conceptual action from the user's perspective, but the underlying primitives remain available for edge cases. Operations can graduate from agent-orchestrated loops to optimized code when performance demands it, while preserving the agent's ability to trigger the optimized path and fall back to primitives.
The architecture suits domains where flexibility, edge-case variety, and emergent capability matter more than auditability and determinism - customer support, internal tooling, creative workflows, and exploratory interfaces where the space of valid actions is large and evolving. Regulated or compliance-critical domains (finance, healthcare, aviation) require the deterministic branching and defensive constraints that agent-native framing treats as anti-patterns, because those constraints exist to satisfy accountability, repeatability, and legal defensibility requirements rather than to limit agent capability.
Latent demand discovery
Agent-native applications can discover what features to build by observing what users ask the agent to do, inverting traditional product development from imagine-build-validate into build a capable foundation, observe, and formalize. When the agent has atomic tools and UI parity, users inevitably ask for things the developer did not anticipate. The agent either composes tools to accomplish the request or fails, revealing a gap. Both outcomes are signal: successful unanticipated requests indicate patterns worth optimizing with domain-specific tools or dedicated prompts, and failed requests expose missing tools or parity gaps.
Over time, the developer adds domain tools for common patterns (making them faster and more reliable), creates dedicated prompts for frequent requests (making them more discoverable), and removes tools that are not being used. The agent becomes a research instrument for understanding what users actually need, grounded in observed behavior rather than upfront feature speculation. Customer support agents are a concrete instance: observing what customers ask the agent to do (and where it fails or escalates) reveals unmet support needs and missing knowledge base content.
Patterns the source material distinguishes from agent-native
The source material identifies several approaches as distinct from the agent-native model:
- Agent-as-router - using the agent only to dispatch to pre-built functions
- Request/response thinking - single-turn execution without a loop
- Workflow-shaped tools - bundling judgment into tool implementations
- Defensive tool design - constraining inputs to prevent unanticipated compositions
- Coded edge-case handling - encoding branching logic into application code rather than delegating to the agent
Several of these - particularly defensive tool design and coded edge-case handling - are deliberate design choices in contexts where auditability, security, or compliance take priority over flexibility. The distinction is between domains where agent judgment adds value and domains where deterministic behavior is a requirement.
Counterarguments
- Delegating judgment to the agent on every request trades predictability for flexibility. For production systems where consistent, auditable behavior matters (finance, healthcare, compliance), non-deterministic agent judgment is a liability rather than a feature. Many domains require that the same input always produces the same output, which agent loops cannot guarantee.
- The framing of coded edge-case handling as an anti-pattern ignores that deterministic branches are often a regulatory or business requirement, not a limitation of imagination. "Let the agent handle it" is not an acceptable answer when the handling must be documented, repeatable, and legally defensible.
- Atomic tools with full parity create a large, unsecured action space. The more capable the agent becomes (approaching full UI parity), the larger the tool misuse and prompt injection attack surface. The "defensive tool design" that the note dismisses as an anti-pattern is often a deliberate security constraint.
- Observing what users ask an agent to do conflates demand with curiosity. Users experiment with novel interfaces, and early-adoption requests may not reflect sustained needs. Formalizing features based on exploratory usage risks building for novelty rather than durable demand.
- The latent demand signal depends on the agent being capable enough to attempt (or clearly fail at) the requested task. If the agent silently produces poor results rather than clearly failing, the developer gets a false positive - apparent success that masks an unmet need rather than revealing one.
- Demand discovery favors incremental feature additions within the existing tool space. It is less effective at surfacing needs that require fundamentally new capabilities the agent cannot approximate by composing existing primitives.
- The granularity and emergent capability principles may be internally inconsistent. Emergent capability - agents composing tools in unanticipated ways - is framed as a benefit, but unanticipated compositions are difficult to distinguish from uncontrolled behavior in practice. Without a mechanism for telling the difference between a valuable emergent pattern and an unsafe one, the architecture lacks a principled way to encourage the former while preventing the latter.
- When features emerge from agent loops rather than coded paths, tracing why a specific outcome occurred is much harder than tracing through deterministic code. Standard observability tooling - distributed tracing, log correlation, error attribution - assumes stable code paths, and agent-loop-driven features produce different execution traces on each invocation even for identical inputs, making debugging and incident response significantly harder.
- Prompt-based features make A/B testing, feature flagging, and gradual rollout harder than code-based features. A prompt change can have unpredictable effects across the full behavior space rather than scoped changes to isolated code paths, making controlled experimentation and incremental deployment - standard practices for managing production risk - difficult to apply.
- Agent loops with LLM inference are orders of magnitude slower and more expensive than coded paths. The note mentions graduating operations to optimized code when performance demands it, but this is a fundamental constraint rather than an edge case: any latency-sensitive or high-throughput interaction is impractical at the agent-loop layer, limiting the architecture to domains where response time is not a binding constraint.
Confidence
Low. The five principles are well-articulated as a design philosophy, but the counterarguments around predictability requirements, regulatory compliance, and the security implications of full tool parity substantially limit applicability to domains where flexibility and emergent capability outweigh auditability and determinism.