Agent-Native Spine

One product core for people and agents, with shared operations, permissions and scope.

Agent-Native Spine is the architecture I use across my projects. People and agents use the same product operations through different interfaces.

I define each product action once. The app, HTTP API, CLI and MCP tools call the same implementation, with shared validation and access rules.

1 Define each operation once2 Check owner, scope and tool at start3 Serve it to the app, HTTP, CLI and MCP4 Every call follows the same rulesOperationidtask.createownertasksscopeworkspaceschema{ title }Task savedStart checkHas an ownerHas a scopeHas a toolReady to serveCheck permissionAllowedAppAdd task buttonHTTPPOST /v1/tasksCLItasks createMCPtask_create tool
How one operation serves every interface.
Architecture across my projects

The common architecture behind my projects: an operation catalog, shared product logic, caller permissions and explicit checks before startup.

Why it matters

Agents need a clear model of what a product can do. Shared operations keep the product rules consistent as interfaces and features change.

What I built

  • Operations before interfaces. Each product action has an identity, input and output contracts, an owner and a scope. Interfaces connect to that operation model.
  • One implementation of the product rules. A shared core holds the product behaviour. Thin adapters connect the app, HTTP, CLI and MCP to that core.
  • Permissions for each caller. People and agents use the same access checks. Each caller has its own identity, capabilities and permitted scope.
  • Checks before startup. Each host connects checks for missing handlers, operation ownership, permissions and scope coverage. A failed check can stop startup.
  • A structure I reuse. Each project supplies its own product logic, storage and adapters. The operation model and checks remain consistent across projects.

Where I use it

  • ShappyOS. Tasks, Bots and Chat use shared operation contracts, caller permissions and scope checks. Product changes run through Dromio workflows.
  • This portfolio. The content editor, HTTP API, CLI and MCP tools call the same content service. Saves validate the input and reject stale revisions.