HEnRY

Make organizational boundaries executable in multi-agent systems.

HEnRY is a domain governance layer for systems where agents must collaborate without collapsing HR, finance, legal, healthcare or personal context into one shared prompt. It turns domain ownership, capability contracts, purpose limitation and controlled context sharing into enforceable runtime decisions.

HEnRY is provider-neutral. OmniAgent is the default execution adapter today; the original research prototype used MemGPT/Letta.

Status: alpha. The governed execution path is implemented and tested. Durable storage, production identity and complete facilitator/mediator workflows remain on the roadmap.

Organizations are not one knowledge base with one trust boundary. They are made of domains—such as HR, finance, legal or operations—with different owners, data, tools, policies and access rules. A request may need several of those domains, while no participant should automatically see the full user context or another domain's internal state.

The usual approaches force an unsafe trade-off:

The hard problem is therefore not simply routing a prompt to several agents. It is letting one task cross organizational boundaries while every domain retains authority over its capabilities and data, only the minimum authorized context is disclosed, and every delegation and result remains reconstructable.

HEnRY addresses this as a governance problem above the execution runtime. Read the full problem statement.

Most agent frameworks answer how to run an agent. HEnRY answers the organizational questions that come first:

Agents and providers are replaceable implementation details. Domain sovereignty and governance remain stable when either changes.

The research landscape and alternatives compares HEnRY with agent protocols, privilege-control middleware, verifiable identity and auditability research.

• Domains own boundaries. Each domain controls its policies, classifications, capabilities, agents, data residency and internal memory.
• Capabilities are the public API. Other domains request a versioned business capability, not unrestricted access to an agent or its tools.
• Context is private by default. HEnRY projects only fields authorized for the declared purpose and capability.
• Facilitators coordinate, mediators govern. Planning never grants universal access; every cross-domain exchange remains policy-controlled and traceable.
• Execution is pluggable. Runtime adapters submit already-authorized work to OmniAgent or another provider without moving governance into that provider.

flowchart LR
    Twin["Digital twin domain"] -->|"Objective"| F["Facilitator"]
    F -->|"Domain-scoped tasks"| M["Mediator"]
    M -->|"Purpose-bound ContextGrant"| HR["HR capability"]
    M -->|"Purpose-bound ContextGrant"| FIN["Finance capability"]
    HR --> HRR["Domain-selected runtime"]
    FIN --> FINR["Domain-selected runtime"]
    HR -->|"ResultEnvelope"| M
    FIN -->|"ResultEnvelope"| M
    M --> Audit["Auditable cross-domain trace"]
    M --> Twin

The demo runtime is deterministic and requires no model credentials.

git clone --branch next https://github.com/2mmanu/henry.git
cd henry
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -e '.[dev]'
HENRY_RUNTIME=demo HENRY_API_KEY=local-demo-key henry-control

Open http://127.0.0.1:8090. The dashboard submits an HR task containing a role and a candidate name, but grants only the role. The result shows that the execution provider received the authorized projection while the candidate identity stayed outside its visibility cone.

From another terminal, the same flow is available as code:

source .venv/bin/activate
python examples/submit_governed_task.py

Read the getting started guide for the API request and expected trace.

The in-memory registry, task repository and ledger are intentionally pilot components. Do not treat the development API-key identity adapter as a production security boundary.

See provider adapters for the extension contract.

henry/contracts/       Domain, capability, task, context and result contracts
henry/policy/          Default-deny authorization decisions
henry/context/         Visibility cones and context grants
henry/tasks/           Task lifecycle, graph and orchestration service
henry/runtime/         Provider-neutral port plus runtime adapters
henry/audit/           Tamper-evident audit events
apps/control_plane/    FastAPI API and local dashboard
examples/              Minimal runnable client flows
docs/                  Concepts, architecture, providers and design history
tests/                 Unit and integration coverage

• Documentation map
• Problem statement
• Research landscape and alternatives
• Getting started
• Domains and sovereignty
• Controlled context sharing
• Architecture overview
• Provider adapters
• Roadmap

Run make check before opening a pull request. Architectural changes should explain their impact on domain sovereignty, visibility, policy and auditability.

• Contributing
• Security policy
• Code of conduct
• Changelog

@article{lacavalla2024henry,
  title={HEnRY: A Multi-Agent System Framework for Multi-Domain Contexts},
  author={Lacavalla, Emmanuele and Yang, Shuyi and Crupi, Riccardo and Gonzalez, Joseph E.},
  journal={arXiv preprint arXiv:2410.12720},
  year={2024}
}

Apache-2.0 licensed. See LICENSE and NOTICE.