An AI agent calls tools: it writes files, sends mail, queries databases. Before it does, something should decide whether it may. flux7 is that something, and it sits beside the agent rather than inside it, so the agent's code does not change.
Three questions have no good answer today, and none of them are the agent framework's job to solve. They are infrastructure questions, the same ones service meshes answered for microservices a decade ago.
Which agent may call which tool? Frameworks do not enforce boundaries. An agent can call anything it discovers.
Who approved that action? Someone clicked yes in a terminal three weeks ago. That decision is gone.
What actually happened? There are logs somewhere. They are not structured, not queryable, and not auditable.
A request climbs only as far as it needs to. Most never leave the first step. The interesting part is the second: a decision taken once is kept, and answers the next identical request on its own.
agent ──► L0 policy engine rules say allow, deny or ask <1ms
│
├─► L1 memory 3 past approvals, 0 refusals ~100ms
│
├─► L1+ arbitration rules engine, then a model ~2-20s
│
└─► L2 human the genuinely new decisions minutes
every decision is written back as a fact, and answers the next one
The sidecar. One Go binary, one YAML file. Speaks MCP over stdio and HTTP, plus plain REST. The agent never knows it is there.
Where decisions are kept as facts rather than as log lines, so they can be recalled and reused instead of re-asked.
The arbitration step. A rules engine first, a language model only for what the rules cannot settle.
The human end: pending approvals, the policy in force, and what the agents have actually been doing.
An API gateway governs traffic between a user and a model. An agent framework runs the agent's own loop. flux7 sits at a third place, between the agent and the tools it reaches for, with one policy per agent and per tool, an approval queue that does not block, and every decision kept where it can be queried.