MCP-native · graph-native · fair-source

The control plane
for your AI agents.

Hodos maps every service, tool, secret and running agent into one live graph — then serves each agent exactly the context it's allowed to reach, over MCP. Context for your agents. Guardrails included.

// fair-source & graph-native — the alternative to Port & Backstage, rebuilt for the age of agents

✓ You're on the list — I'll write when the beta opens.

self-hostable · EU cloud · built by an engineer who shipped the alternatives

What can this agent reach?

Every agent is a node in the graph, filtered by policy on every single call.

reachable(agent)

What breaks if I change this?

Impact analysis across repos, clusters and teams — before the PR merges.

blast_radius(node)

Where is this used, at any depth?

Reverse reachability for any entity — a library, a database, a secret.

where_used(node)

// governed context, over MCP

Agents that understand your system — and can't touch what they shouldn't.

Give an agent raw API keys and you've given it your whole company. Hodos hands it a graph instead: every read filtered by policy, every running agent inventoried alongside the code it came from, every action audited. Connect over MCP and your agents get exactly what they're allowed to see — nothing more.

agent · MCP tool call

// agent asks — Hodos answers, policy filters
→ impact_of_change("checkout-web")

Affected: payment-api (tier-1), ledger-svc
Owners to notify: team-payments
Scorecard: Silver — this change needs Gold
Verdict: block & open a ticket

✗ 3 nodes hidden by policy — the agent never
  saw the prod secrets it isn't allowed to reach

// impact analysis

The question Port and Backstage can't answer.

Flat catalogs store attributes. Hodos stores relationships — so a real query language (OpenCypher) walks your dependency graph to any depth. Multi-hop where-used and blast radius aren't a feature bolted on; they're what a graph is. Ask "what breaks?" and get an answer, not a list.

what breaks if orders-db changes?

MATCH (n)-[:DEPENDS_ON*1..4]->(:service {name:"orders-db"})
RETURN DISTINCT n.name, n.owner

┌──────────────┬───────────────┐
│ 17 services   │ 4 teams       │
├──────────────┼───────────────┤
│ payment-api  │ team-payments │
│ checkout-web │ team-web      │
│ ledger-svc   │ team-fintech  │
└──────────────┴───────────────┘

// batteries included, extensible core

No blank canvas. No waiting for an admin.

docker compose up, connect GitHub, get a catalog with owners and dependencies in minutes — zero modeling. Outgrow the defaults? Define custom entity kinds, scorecards and policies in YAML — versioned in git, reviewed as a PR, applied with a Terraform-style plan / apply. In Port you wait for an admin to build a blueprint. Here, your team ships its own — and review is the guardrail.

ontology/process.yaml

apiVersion: hodos/v1
kind: OntologyKind
metadata: {name: process}
spec:
  attrs:
    criticality: {type: enum, values: [low, high]}
  relations:
    - {rel: IMPLEMENTS, from: component, to: process}

$ hodos plan   # review the diff, like Terraform
$ hodos apply  # exactly what you reviewed

// fair source

Open code. Yours to run. No lock-in by design.

Inspect everything

The enforcement engine is open too — governance you can't audit is governance you can't trust.

Becomes Apache-2.0

FSL-licensed: every release auto-converts to Apache-2.0 after two years. We can't rug-pull you.

Flat pricing, EU cloud

Never per-seat — adoption shouldn't cost you money. Self-host, or a managed cloud hosted in the EU.

The control planefor your AI agents.