We’ve reached the end of Volume I of our series. We’ve explored the problems with "Vibe-based" engineering, the rise of the Cognitive Interface, and the immediate power of the apcore Adapter ecosystem.
But as any experienced engineer knows, a standard is only as good as its foundational principles. In the fast-moving world of AI, where frameworks disappear every six months, how do we build something that will still be relevant in 2030?
In this ninth and final post of our Manifesto, we outline the five design principles that guide the apcore standard.
Principle #1: Schema-Enforced Everything
In the early days of the web, "Postel’s Law" (be conservative in what you send, liberal in what you accept) was the rule. For AI Agents, we believe the opposite is true: Be strict in everything.
Reliability in an Agentic system is impossible without strict contracts. In apcore, a module without a schema is not a module—it is a bug. By enforcing JSON Schema at the protocol level, we ensure that the AI Agent and the code always speak a deterministic, validated language.
Principle #2: Directory-as-ID (Zero-Config DX)
Developer Experience (DX) is not a luxury; it is a security feature. When developers have to manually register every tool in a central configuration file, "Scaling Rot" sets in. People forget to update the config, IDs conflict, and the system becomes a mess.
apcore uses the file system as the source of truth. The path extensions/executor/email/send.py automatically becomes the Canonical ID executor.email.send. This makes discovery natural, scalable, and impossible to "forget."
Principle #3: Progressive Disclosure of Metadata
AI Agents have limited context windows and expensive tokens. You cannot dump your entire 5,000-page API manual into every prompt.
apcore is designed for Progressive Disclosure. The Agent scans short descriptions for discovery, checks annotations for planning, and only reads the full documentation when it’s ready to execute. This "just-in-time" metadata delivery is essential for large-scale Agentic systems.
Principle #4: Language-Agnostic & Protocol-First
An AI-Perceivable module should not be a "Python feature." It is a structural property of the software. Whether your backend is in Rust, TypeScript, or Go, it must project the same "Cognitive Interface."
By prioritizing the Protocol Specification over any individual SDK, we ensure that an enterprise can build a heterogeneous, multi-language workforce that speaks a single semantic language.
Principle #5: Governance as a First-Class Citizen
Safety is not an "add-on" you prompt-engineer at the end. It must be baked into the lifecycle. Access Control Lists (ACL), Human-in-the-Loop (Approval Gates), and Structured Error Guidance are core primitives of the apcore protocol.
We don't "ask" the AI to be safe; we enforce safety at the runtime level.
Summary of Volume I: The Manifesto
We started this series with a goal: to move from "Prompting Tools" to "Engineering Modules." Over these nine articles, we’ve laid out the vision for an AI-Perceivable World.
We’ve shown that:
- Reliability comes from Enforcement, not better prompts.
- The Cognitive Interface is the next layer of the stack.
- The Adapter Pattern allows one module to serve MCP, A2A, CLI, and Web.
What’s Next: Volume II — The Core Protocol Deep Dive
Now that we’ve established the Why, it’s time to look at the How. In our next volume, we will go "Under the Hood." We’ll look at the actual algorithms behind Directory-as-ID, the 11-step Execution Pipeline, and the math of pattern-based ACL.
Stay tuned. The deep dive begins.
This is Article #9 of the **apcore: Building the AI-Perceivable World* series. Join us in building the architecture for the next decade.*
GitHub: aiperceivable/apcore
SOCIAL SHARE CARD GENERATOR