The policy layer's input is still a person and three things sessions could derive instead

[rafaelasor]

The Databricks post says it well: "Describe the guardrail you want in plain language, and Omnigent turns it into a policy you approve and apply." That works, and it leaves three gaps that show up exactly where Omnigent is strongest, multi-agent sessions:

1. A described policy is written once, but a session's sub-agents differ. Nothing narrows a policy across a handoff, so a sub-agent holds whatever the session holds.
2. The person writing the description has to already know the tools and the tasks. The session object already knows both; permissions could be derived from it instead of described to it.
3. The record of what was allowed lives inside the harness. An auditor has to trust it rather than verify it.

We built an engine for exactly these three, and it already runs against Omnigent unmodified: a policy handler that computes each sub-agent's permission set as a subset of its parent's and enforces it in-process on every tool call. The log is hash-chained and verifies offline, harness absent. The repro is in the repo (examples/integrations/omnigent, built against omnigent 0.11.0), takes about three minutes, no API key.

If the maintainers see a shape where this belongs behind the policy layer rather than beside it, I would like to hear what that shape is. The engine is Apache-2.0 and embedding it is the point.

— Rafael (I maintain attenu-guard)