SETT Framework - Deterministic Governance for Multi-Agent AI Systems

Community Corner Showcase Projects & Demos
, ,
1

Hi AMD Developer Community,

I’m Dan, founder of 4HumanityAI, and I’d like to share SETT (Scalable Expert-based Task Topology), an open-source framework I’ve been developing for governed multi-agent AI systems.

The problem

Many agentic AI architectures allow the language model to participate directly in routing, execution, and sometimes even governance decisions. This makes system behavior harder to reproduce, audit, and contain as agents gain access to tools and real-world actions.

What SETT does

SETT separates probabilistic LLM reasoning from deterministic control.

The language model can reason and generate language, but deterministic components retain authority over routing, governance, and execution.

High-level SETT topology: deterministic orchestration, domain-owned agents, specialized experts, isolated private memory, and explicitly shared universal memory.
High-level SETT topology: deterministic orchestration, domain-owned agents, specialized experts, isolated private memory, and explicitly shared universal memory.3270×2423 381 KB

Key capabilities currently include:

  • deterministic orchestration
  • fail-closed pre-execution governance
  • ALLOW / WARN / DENY safety decisions
  • tamper-evident SHA-256 audit trails
  • end-to-end causal tracing
  • modular agents, experts, and model adapters

SETT's execution boundary: proposed actions pass through deterministic governance before any real-world effect is allowed to occur.
SETT's execution boundary: proposed actions pass through deterministic governance before any real-world effect is allowed to occur.1672×941 128 KB

Current state

SETT is currently at v0.11.0 and has 340 automated tests passing from a clean installation.

The architecture has also been exercised through a full private reference implementation and additional standalone implementations in different domains to test whether the governance model generalizes beyond its original use case.

One of the core execution paths is submit_action(), where an action cannot reach a registered handler without first receiving an explicit governance verdict.

Fail-closed action flow: only explicitly approved actions can invoke a real-world handler; rejected actions produce no effect while preserving an auditable decision trail.
Fail-closed action flow: only explicitly approved actions can invoke a real-world handler; rejected actions produce no effect while preserving an auditable decision trail.2752×3420 428 KB

The private implementation remains confidential, but it serves as a real-world proving ground for new framework requirements rather than as a synthetic demo.

Why I’m joining the AMD ecosystem

SETT is currently hardware and model agnostic. As part of the AMD AI Developer Program, I want to explore AMD Developer Cloud and ROCm-based inference as a reproducible environment for governed agentic workloads.

My goal is to evaluate:

  • local and cloud inference paths
  • performance overhead introduced by governance and tracing
  • model-adapter portability
  • deployment patterns for multi-agent workloads on AMD infrastructure

I’d be particularly interested in feedback from the AMD community on benchmarking methodology, ROCm deployment, and useful agentic workloads to evaluate.

If you’re curious about SETT, you’re also very welcome to explore the repository, experiment with it, and open issues for bugs, edge cases, unclear behavior, documentation gaps, or ideas worth discussing. Community feedback is especially valuable at this stage: it helps me identify things I may have missed, prioritize improvements, and keep evolving the framework based on real developer experience rather than assumptions.

A small note: this is my first post in the AMD Developer Community, so I’m still getting familiar with the space. If there’s a better category, format, or way to present this kind of project, please feel free to let me know.
Constructive criticism is absolutely welcome, both here and through GitHub issues.

Links

GitHub:

Technical paper:

2 Likes
2

Interesting project, Thank you for sharing.
One question I had while reading about the governance layer:

How do you see SETT differing from the permission/confirmation mechanisms already built into systems like ChatGPT or Claude, where the user can be asked to approve or deny an action before it executes?

I understand that SETT is aiming for deterministic, fail-closed governance rather than relying on the LLM itself. I’m curious what guarantees or capabilities SETT provides beyond what could be achieved by putting a deterministic policy/authorization layer in front of an existing agent framework.

For example, is the key distinction that SETT can enforce ALLOW/WARN/DENY policies even without human intervention, while also guaranteeing that a denied action cannot reach the execution handler?

That seems like an interesting area to benchmark against existing agent frameworks.

3

Thank you very much for taking the time to read through the project and leave such a thoughtful question. I genuinely appreciate it, especially because this touches on one of the architectural ideas I have been trying to explore with SETT from the beginning.

I would not say that deterministic authorization or policy enforcement cannot be added in front of an existing agent framework. It absolutely can, and I think that is actually an important comparison to make.

The distinction I am aiming for with SETT is less about adding another safety layer around an LLM and more about where authority lives within the application architecture.

In SETT, the LLM is not intended to be the authority that decides whether an external action is permitted. It can interpret intent, reason about a problem, propose an action, generate content, or verbalize a decision, but authorization belongs to a separate deterministic control path.

Conceptually, I am aiming for something closer to:

intent/task → deterministic governance → ALLOW / WARN / DENY → execution

rather than:

LLM proposes/decides an action → user confirms → execution.

Human confirmation can still be part of a policy when it is appropriate, but I do not think the safety of the system should depend on the user always being able to recognize whether an LLM-proposed action is safe or appropriate. In some contexts, the user may simply not have enough technical or contextual information to make that determination. We have seen similar concerns recently in stories where AI systems were given capabilities or permissions under poor initial configurations and then behaved in unexpected ways.

So yes, the property you mentioned is an important part of what I am trying to enforce: if governance returns DENY, the action should not be able to reach the execution handler. The LLM should not be able to reinterpret, override, or bypass that decision.

At the same time, I do not see SETT as needing to replace or compete with, let’s say, LangGraph, LangChain, or other existing frameworks for this idea to be useful.

Composability is actually one of my goals. If an application already has an orchestration stack that works well, but can benefit from SETT’s deterministic governance model or execution boundary, I would consider using only that part of SETT a perfectly successful outcome.

That is also one of the reasons I chose to make the project open source. I am much more interested in whether these architectural ideas are useful and reusable than in making SETT an all-or-nothing framework.

So, if someone implemented an equivalent deterministic policy layer on top of another framework and achieved the same guarantees, I would not consider that a failure of SETT’s premise. In many ways, it would validate the architectural idea.

The interesting question then becomes not “can this only be done with SETT?” but rather whether SETT can make these properties easier to define, enforce, test, trace, and preserve as an application becomes more complex.

And I completely agree with your last point. I think benchmarking this against existing agent frameworks, including a framework with an ad-hoc deterministic policy layer versus one using SETT’s governance boundary, could be a very interesting experiment. And that might be my next goal once I wrap up a few remaining items on my roadmap.

Thank you again for taking the time to read my post and for asking the question. It gives me some very useful guidance on how to evaluate and communicate this part of the project more thoroughly.

1 Like
4

Thanks for the detailed response, Eduardo!
Framing SETT around moving authority away from the LLM, rather than just adding another approval gate which makes total sense.

You’re spot on about human-in-the-loop limitations too, users can’t always judge if a technical action is safe. I love that it’s composable with tools like LangGraph, and I’ll definitely be looking out for those benchmark results down the road!

1 Like
5

Thanks again for the question you raised on my original SETT post.

I ended up turning it into a benchmark rather than answering only conceptually. SGBS-01 is now published, comparing SETT native governance against a LangGraph baseline and a manually added deterministic policy layer.

The result was actually more interesting than a simple “SETT wins” or “SETT loses”: the LangGraph + policy implementation reproduced the same tested boundary behavior, while the differences appeared in structural integration, native audit evidence, and runtime overhead.

I posted the full results here in the community, and the paper + frozen artifacts are available in the post.

Your question directly influenced what I decided to measure, so thank you again for pushing on that point.

1 Like
6

Hello. One thing on benchmarking: I’d measure governance in microseconds per action instead of % overhead. The model call is so slow that governance will always look like ~0%, and that number won’t carry over if you swap an MI355X for a small local model. More useful is how the cost grows as you add policies, and as the audit chain gets longer. Does verifying the chain stay fast after a million entries, or does it start dragging?

Also curious, do your policies check the action’s arguments or just the action type? Blocking delete_file works fine. But if send_email is allowed, the model still writes the recipient and the body, so a prompt injection could push data out through a channel you already approved.

7

Thanks a lot for the comment, these are very useful points.

For the first experiment, I deliberately kept the LLM out of the benchmark so that governance cost could be measured directly instead of being hidden by model latency. The detailed results are already published in microseconds per action, including mean, p50, p95, p99 and throughput.

I posted the results here in the AMD Developer Community, and the full methodology and measurements are also available in the SGBS-01 paper on Zenodo in case you’re interested in taking a look.

The next stages of the benchmark series will bring the LLM back into the loop, first with local models and then with a cloud-based setup, so the interaction between model latency and governance overhead can be measured separately as well.

Your points about policy scaling, audit-chain growth, and argument-level authorization are especially interesting, and thanks to them, I’ve already figured out what I’ll be working on this week. If you have any other recommendations or edge cases you think would be worth testing, they’re very welcome.

On your send_email example specifically: in current SETT v0.13.2, policies are not limited to the action type. The Executor snapshots the Action payload, passes its fields into the policy context, and then executes that same approved snapshot, so a domain policy can reject an otherwise valid capability based on its actual arguments, recipient, resource, scope, or other application-defined constraints. What SETT does not automatically know is which recipients or data are authorized; that remains part of the implementation’s policy. So the mechanism is already there, but an overly broad application policy could still be underspecified, which is exactly the kind of case I now want to stress-test with LLM and prompt-injection scenarios.

SGBS-01 results: SGBS: SETT Governance Benchmark Series
Paper: SGBS-01: Deterministic Governance Boundary Benchmark | Zenodo

2 Likes
8

That’s awesome to see, Eduardo! Really cool that you turned that question into full-blown benchmark data.

The distinction between boundary behavior and the operational realities (audit chains, overhead) is where the real value is. Great work on SGBS-01!