Delegatic is the authorization layer of ComputeDrivenlive_deployedThat rung covers the policy kernel answering at delegatic-mcp.fly.dev/health, and nothing else — its policy store is empty, and the org trees, the effective-policy computation and the compliance proofs described below are specified rather than written.
The question this site exists to answer

Was this delegation actually permitted?

The interoperability protocols carry a delegation perfectly well. What none of them carries is the rule that says whether the delegation was allowed in the first place — who may be admitted, who may invite, who may be removed, who holds which role. Delegatic is two things with one name, and the difference matters: a policy kernel that is deployed and answering, with an empty policy store; and a governance platform that is specified and not built. Every claim below says which one it belongs to.

Where this stands, before anything else on the page

One deployed kernel with nothing in it, and a platform on paper.

Status
live_deployed — A policy kernel is deployed and answers. Eight modules, three test files, forty-two tests, six MCP tools, five typed refusal reasons. FleetPrompt calls delegatic_authorize to authorize an install and the kernel answers with a signed, expiring authorization block or a typed refusal. The governance platform described on this page — org trees, policy cascade, compliance proofs, the dashboard — is none of it written.
Last verified
2026-08-16
Source
curl -s https://delegatic-mcp.fly.dev/health, run 2026-08-16; and the module, test and tool counts derived from the delegatic/ tree at commit 06dfa88 by counting files and test macros, not by copying a planning document.
Limit
This establishes that a service answers and that a test suite passes. It does not establish that any policy has ever been enforced in anger: policies_registered is 0, the store is in-memory ETS and empty on every cold start, and require_approval_by is stored and published and checked by nothing. It says nothing at all about the org hierarchy, the policy cascade or the audit trail described further down, none of which exist.
Next rung
external — Someone who is not us registering a policy in a Delegatic kernel and having it refuse something. That is the one rung nobody here can award themselves. The nearer, cheaper move is to make require_approval_by a check rather than a field — which would close the fourth of G1's four words instead of naming it.
The gap

A2A can already delegate. That is not the missing part.

The claim this page was drifting toward — that the interoperability protocols cannot delegate — is false, and the source we would have cited for it says the opposite in as many words. It is corrected out loud here rather than quietly avoided. The real gap is narrower, and it is stronger for being narrower.

Was this delegation actually permitted?

Source. Richard Kang and Yudho Diponegoro, Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express, arXiv:2606.31498v1, 30 June 2026. This is a preprint. It has not been peer-reviewed, and its authors record that the “Partial” classification “involves judgment.” It scores five protocols against six governance dimensions: 2 points for Supported, 1 for Partial, 0 for Absent, over six dimensions — 12 possible. Read it and disagree with it; that is the point of citing it rather than summarising it.
MCP v1.1 — 1/12A2A v1.0.1 — 1/12ACP — 2/12ANP — 0/12ERC-8004 — 2/12
What the paper actually says about A2A, quoted. “A2A supports task delegation and message exchange.” So delegation is missing is not a claim available to this page, and any earlier reading of it that way was wrong. What the paper scores is G1 Membership — “admission, invitation, removal, and role assignment” — where A2A is graded Partial and 1/12 overall, because “an agent ‘exists’ by publishing an Agent Card; there is no concept of community membership distinct from existence.” Those four words are the four cards below. Two of them are gaps in this kernel too, and they are the point of the section.
1AdmissionA2A: partial
A2A: an Agent Card declares what an agent can do. Nothing declares what it may join.
A policy names an explicit allow_actions list and an optional agents allowlist. Nothing is implicitly granted: an unset key is denied, not inherited as true.
refuses: :agent_not_allowed · :not_in_allowlist
2Invitationabsent here too
A2A: no invitation primitive. The paper's finding, and it holds against this kernel too.
The kernel has none either. A policy is written by whoever can reach the policy store; there is no protocol for one principal to admit another, and no endorsement chain of the kind the paper's own worked example uses.
not built · named here rather than implied by the other three
3Removalpartly, and only partly
A2A: no removal primitive. An Agent Card that exists keeps existing.
Two mechanisms, and only one of them is revocation. A deny_actions entry beats the allowlist on conflict. Separately, every issued authorization carries a TTL capped by the policy — max_ttl_seconds, 600 by default — so authority lapses on its own. Expiry is not revocation: a block already issued stays valid until its TTL runs out.
refuses: :denied_by_policy · :expired
4Role assignmentstored, and unenforced
A2A: capabilities are declared; governance roles are not modelled at all.
A policy can carry require_approval_by, and the MCP get_policy tool reports it. And nothing enforces it. The authorize path checks the denylist, the agent allowlist and the action allowlist, then signs whatever approved_by the caller asserted. The field is stored and published; it is not a check. This is the honest state of the fourth word, and it is written down here because a governance kernel that quietly ignores its own approval field is worse than one that never offered it.
gate approval_field_enforced · pending, and it is the nearest real advance available to this surface
What is actually running

One command, and the number in the answer is the point.

This is the only thing on the page you can check without reading a specification. It is printed exactly as it came back.

$ curl -s https://delegatic-mcp.fly.dev/health
{"status":"ok","version":"0.1.0","service":"delegatic","policies_registered":0}

Eight modules, three test files, forty-two tests — twenty-five unit, three integration, fourteen across the six MCP tools. FleetPrompt calls delegatic_authorize to authorize an install; the kernel answers with a signed, expiring authorization block, or with one of five typed refusals. Every one of those counts was derived by counting the tree at the commit named in the status block above, not copied out of a planning document.

The number that matters in that response is policies_registered: 0. Nobody has written a policy into the deployed store, which is in-memory ETS and empty on every cold start — a Postgres-backed store is a future additive release, not a thing that exists. It runs on Fly today because that is where it was put, and the standing direction moves compute off Fly, so treat the hostname as this month's address rather than the product.
The specified model — none of this is implemented

Structure is the authorization model.

Everything in this section and the two below it is a design. The containment tree, the cascade, the invariants: specified in docs/spec/README.md and written nowhere else. The worked example is an illustration, not a screenshot of a running system, and it is drawn as a table for that reason.

Acme Corproot org

maxAgents: 500 · telespaceAttach: true · externalAPI: true — the owner sets the outer boundary. Everything below can move inward from here and nowhere else.

Engineeringchild org

maxAgents: 200, tightened. telespaceAttach and externalAPI inherited. A child that states nothing states its parent.

ML Teamgrandchild

maxAgents: 50 and externalAPI: false, both tightened. Two levels down, still strictly inside both ancestors.

Intern Teamgrandchild · restricted

maxAgents: 5 · externalAPI: false · telespaceAttach: false. An attempt to set externalAPI: true here is rejected — it would widen a parent restriction, and that is a privilege escalation whichever direction it is written from.

spec §3.5 effective policy computation · ADR-0002 — children may only tighten, never widen; escalation impossible by construction rather than by review

What Delegatic is

  • A governance plane — who may do what, enforced
  • An org hierarchy — containment trees with a policy cascade
  • Authority delegation — structured permission grants
  • Audit and compliance — immutable decision records
  • Human-defined structure — you design the rules
  • Orchestration — defining workflows and routing policies

What Delegatic is not

  • Task execution — that is AgenTroMatic
  • Agent building — that is Agentelic
  • A skill marketplace — that is FleetPrompt
  • Runtime hosting — that is WebHost.Systems
  • Agent self-organisation — that is AgenTroMatic
  • Memory or learning — that is Graphonomous
The primitives, as specified

Six ideas, and the fifth is why the data layer stays small.

Containment trees

Organisations nest in a strict tree — no cycles, enforced at write time. Each org has at most one parent. The structure is the authorization model rather than an index over it.

Specified in: §3.1 organizations · §4 cycle detection

Policy inheritance

Policies cascade down the tree. Children can tighten but never widen a parent restriction. Monotonic inheritance makes privilege escalation impossible by design rather than by audit.

Specified in: §3.4 policies · §3.5 effective policy

Deny by default

No implicit permissions. Every capability must be granted explicitly at some level of the tree. Unset is denied. No confused-deputy attacks.

Specified in: §3.4 policies. Running: this one is real in the deployed kernel.

Append-only audit

Every policy mutation, every delegation decision, every access attempt is logged immutably. The audit trail is the compliance artifact; there is no second document to keep in step with it.

Specified in: §3.6 audit events

References, not copies

Delegatic stores org IDs, telespace IDs, policy rules and GoalGraph goal_id references. It never copies agent configs, messages, execution logs or goal content — only opaque IDs. Zero data duplication.

Specified in: §2.1 GoalGraph integration · §3.2 goal attachments

Human in the loop

Escalation paths for low-confidence decisions, and an override on any agent decision with full audit logging. Humans set the structure; agents operate inside it.

Specified in: §3.3 memberships · §5 dashboard
The security model, as specified

Four invariants, and the honest note about all four.

These are properties the specification says hold at every level of the containment tree, verified on every write. Nothing verifies them today, because the containment tree is not implemented — the deployed kernel is flat: one policy, one action type, one agent filter. These are stated as design, and the gate on this page refuses any wording that would let them read as behaviour.

1

No cycles in the containment tree

Every org has at most one parent. Cycles are rejected at write time with a traversal check. Maximum depth 50, maximum 10,000 nodes; an attempt to create a cycle returns CONFLICT. spec §4 · ADR-0001

2

Monotonic policy inheritance

A child's effective policy is always at least as tight as its parent's. Attempting to widen — setting externalAPI: true where the parent says false — is rejected as a privilege escalation. Delegatic governs authorization boundaries; the κ invariant in Graphonomous determines where deliberation is structurally meaningful within those boundaries. spec §3.5 · ADR-0002

3

Deny by default

No capability is implicitly granted. If a policy key is unset at any level, the effective value is denied. Explicit grants are required at every boundary. This one is real in the deployed kernel — it is the rule behind :not_in_allowlist. spec §3.4

4

Append-only audit

Every mutation — policy change, org creation, delegation grant, override — logged with actor, timestamp, previous value and new value. Logs are immutable. spec §3.6

Where it sits

The boundary every other product operates inside.

Delegatic defines the boundary; the rest of the stack works within it. The rungs differ wildly and the list says so — a stack diagram that draws eight products as equal peers is drawing a wish, and this one is a list precisely so it cannot.

Delegaticauthorization · you are here

Org hierarchy, policy inheritance, authority delegation. The kernel is deployed with an empty store; the platform is specified.

SpecPromptspecifications

Agent capability contracts and acceptance criteria.

Agenteliccollaboration

Telespaces, rooms, and agent team communication.

AgenTroMaticallocation

Bidding, debate and quorum over contested work. A specification, and its page says so.

Deliberaticdecisions

Argumentation-based consensus. A specification, and its page says so.

FleetPromptskills

Agent skill marketplace and component registry. It is the one caller of delegatic_authorize today.

Graphonomouslearning

Continual learning engine — the memory the rest of the stack reads from.

WebHost.Systemshosting

Managed infrastructure. Its own page is being rewritten; do not take anything here as a claim about it.

What you can do here

Two rungs, two sets of verbs, and neither borrows the other's.

The kernel is live_deployed and there is exactly one thing to do with it. The page above it is spec, and a specification has nothing to run. The publication gate refuses to emit a call to action the rung has not earned, which is why there is no button here inviting you to try a governance platform that does not exist.

Retraction — what used to stand here

“Enterprise governance. Open-source core. Launching 2026.” stood here, above an email box wired to nothing — no form, no handler, no destination. It is August. Both are gone rather than moved to a later year. A footer mailto: went with them in this revision: Cloudflare was rewriting it at the edge for obfuscation, which is the entire reason the served page measured 159 bytes larger than the file in this repository.

Tell us where this specification is wrong

The kernel is deployed and the page above it is a specification, so the most useful thing a visitor can send is a containment rule that does not hold, an invariant that is weaker than it reads, or a number on this page you think is wrong.

This box is not that one. The retraction above names what the old one lacked. This is a plain <form action method="POST"> posting to formspree.io when you press Send, so it delivers with scripting switched off entirely; the script that upgrades it to an inline reply prints “sent” only after the endpoint returns a 2xx, and prints what went wrong otherwise. Ruled 2026-08-17: the same endpoint computedriven.com uses. The publication gate still refuses any address link anywhere on this page.