Hodos maps every service, tool, datastore, owner 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.
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 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
Flat catalogs store attributes. Hodos stores relationships — so a real query engine walks your dependency graph with bounded, budgeted traversal. 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.
$ hodos impact orders-db --max-hops 4 ┌──────────────┬───────────────┐ │ 17 services │ 4 teams │ ├──────────────┼───────────────┤ │ payment-api │ team-payments │ │ checkout-web │ team-web │ │ ledger-svc │ team-fintech │ └──────────────┴───────────────┘
docker compose up, connect GitHub, get a catalog with owners and dependencies in minutes — zero modeling. This is the internal developer portal underneath: the same map your platform team already wants, doing double duty as the governance context your agents read from. 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.
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
The self-hosted core and the managed cloud are what you can start on today. Enterprise and Own Cloud are in progress — reach out and we'll bring the graph to your environment ourselves.
Self-hosted core, FSL-licensed. Catalog, impact analysis and MCP context for one team's agents. Runs on your own infrastructure.
Get early access →The same graph, managed for you — hosted in the EU. For a team that wants it without running Postgres + AGE themselves.
Get early access →SSO/SCIM, ReBAC at scale, audit — source-visible, key-gated. Self-hosted first, sold direct.
Talk to us →A dedicated, single-tenant deployment we run for you in the EU — managed, without shared infrastructure.
Talk to us →The enforcement engine is open too — governance you can't audit is governance you can't trust.
Fair-source, not open-source: FSL-1.1-ALv2 today, and every release auto-converts to Apache-2.0 two years after it ships. We can't rug-pull you.
Team and Own Cloud are built to run in the EU, on EU-owned infrastructure, from an EU company. The question is which jurisdiction can compel access — a US hyperscaler's EU region can't fully answer that; ownership decides it, not geography alone.