English · 中文

Governed capability standards for agent-callable software · schema-enforced modules · protocol-neutral execution boundaries

I work on the boundary where an agent stops reasoning and starts causing things to happen.

MCP tells an agent what it can call. apcore decides whether this call — with these arguments, in this environment, by this identity — should happen at all, and leaves evidence that it did.

Most of the agent-tooling stack today is a discovery problem solved twice and an authorization problem solved zero times. A tool schema tells a model how to format a call. It says nothing about who may make it, what it may touch, whether a human must approve it first, or what record survives afterwards. Those questions do not belong in the model's reasoning loop — they belong at the execution boundary, enforced identically no matter which protocol carried the request.

That is the position apcore takes:

                  ┌──────────────────────────────────────────┐
                  │     Agent  ·  Human  ·  Application       │
                  └────────────────────┬─────────────────────┘
                                       │
          ┌──────────┬──────────┬──────┴────┬──────────┬──────────┐
          ▼          ▼          ▼           ▼          ▼          ▼
       ┌─────┐   ┌───────┐  ┌───────┐   ┌──────┐   ┌───────┐  ┌────────┐
       │ MCP │   │  A2A  │  │  CLI  │   │ HTTP │   │OpenAI │  │ direct │
       └──┬──┘   └───┬───┘  └───┬───┘   └──┬───┘   └───┬───┘  └───┬────┘
          └──────────┴──────────┴─────┬────┴───────────┴──────────┘
                                      ▼
              ╔═══════════════════════════════════════════════╗
              ║              apcore runtime                   ║
              ║   schema · ACL · approval gate · middleware    ║
              ║          observability · audit trail          ║
              ╚═══════════════════════┬═══════════════════════╝
                                      ▼
                  ┌──────────────────────────────────────────┐
                  │      your existing business logic        │
                  │           (unchanged)                    │
                  └──────────────────────────────────────────┘

Define a governed capability once. Expose it through any surface. The guarantees do not change when the transport does.

Everything below lives under @aiperceivable.

Core standard — a protocol specification with three independent implementations, held together by cross-language conformance fixtures rather than by a shared codebase. Full documentation →

Surface adapters — the same module, projected onto a different protocol. Each is specified once and implemented three times, with a shared conformance suite pinning the behavior that must match.

Meeting code where it already is — integrations that scan an existing codebase and expose what is already there, rather than asking anyone to rewrite it.

fastapi-apcore · django-apcore · flask-apcore · nestjs-apcore · hono-apcore · axum-apcore · tiptap-apcore

And in the other direction — pydantic-ai-apcore hands governed modules to a pydantic-ai agent as a toolset, and registers the tools that agent already has as apcore modules, so they arrive over MCP, CLI, or A2A carrying the same ACL, approval, and audit semantics as any other.

And for the code that has no framework at all — apexe wraps an existing CLI binary into a governed module by scanning its help output, so a forty-year-old tool arrives at an agent with the same ACL and approval semantics as a hand-written one.

Orchestration — apflow, distributed task orchestration where every capability in the graph is itself an apcore module.

Separately, a set of Claude Code skills for the parts of engineering that reward a checklist over improvisation:

aiperceivable.com · @tercelyi · LinkedIn

Issues and design discussions are welcome on any repository above — particularly the hard parts: authorization semantics, cross-language conformance, and what an agent is entitled to assume when a call comes back denied.