agent-native-architecture

Agent-native architecture separates decision logic in prompts from atomic tool actions, enabling agents to behave with parity to user capabilities. Start with a system prompt describing intent, atomic tools (read_file, write_file, list_files, bash), and explicit completion signaling via a complete_task tool to govern agent behavior end-to-end.

Prompt-native design embeds logic in prompts alone; agent-native design pairs prompts with atomic tool primitives and explicit completion signals. This achieves parity—every user action maps to an agent tool—enabling predictable, composable automation without baking complex logic into tools.

Agent-native architecture supports dynamic context injection and persistent state through structured frontmatter (name and description) and atomic primitives. Use read_file and write_file to maintain state, and rely on prompt governance to orchestrate context across loop iterations and completion signals.

Yes. Agent-native design promotes composability by separating governance (prompts) from actions (tools). Add optional domain prompts or new tools incrementally by observing user requests, then test with open-ended tasks—no code changes to core architecture required.

Explicit completion signaling via a complete_task tool is mandatory in agent-native architecture. It governs lifecycle management, resilience, and edge-case handling in long-running agent loops, ensuring predictable task termination and state finality.

Parity-driven design mandates that every user action have a corresponding agent tool. Map user workflows to atomic primitives (read_file, write_file, list_files, bash), define outcomes in prompts, then iterate by adding domain tools or prompt sections as new use cases emerge.