First of all, thank you for the work on DwarfStar. I find the project especially interesting because it combines local inference, tool calling, KV state handling, server APIs and an integrated agent in a very focused way.
I would like to propose a feature that could make ds4-agent and ds4-server more suitable for enterprise, regulated and mission-critical use cases: decision gates.
Motivation
In many enterprise scenarios, agents are (or will) not only used to generate text or code, but to support or execute operational decisions: modifying production systems, approving business workflows, changing customer records, triggering financial actions, interacting with ERP/CRM systems, or executing actions that may have legal, safety, operational or compliance implications.
In those contexts, not every agent decision or tool call should be executed immediately. Some actions should be suspended and mediated by an external supervisor before the agent continues.
The supervisor could be:
- a human operator;
- a governance / risk / compliance system;
- a workflow engine;
- a policy service;
- another specialized agent;
- an external authority or approval service.
This is also relevant for AI governance. For example, under the EU AI Act, high-risk AI systems must support effective human oversight. I am not suggesting that ds4 should implement legal compliance as such, but that a small technical primitive for supervised execution would make it much easier for downstream systems to implement these requirements.
Proposed concept
A decision gate would be a controlled suspension point in the agent execution flow.
When the model produces a tool call or decision that matches a configured gate policy, ds4 would not immediately execute or return it as a normal tool call. Instead, it would emit a structured approval request and preserve the agent/session state until an external decision is provided.
Possible decision outcomes:
approved: continue and execute / return the proposed action;
rejected: continue the agent with a rejection result;
modified: continue with externally modified arguments or instructions;
expired: continue or fail according to a timeout policy.
Example
A tool could be marked as requiring approval:
{
"name": "deploy_to_production",
"description": "Deploys a service to production",
"x-ds4-decision-gate": {
"required": true,
"policy": "external_supervisor"
}
}
When the agent attempts to call it, ds4 could emit something like:
{
"type": "decision_gate.required",
"gate_id": "dg_123",
"session_id": "session_456",
"reason": "The agent requested a production-impacting action",
"proposed_action": {
"tool": "deploy_to_production",
"arguments": {
"service": "billing-api",
"version": "1.4.2"
}
}
}
An external supervisor could then respond:
{
"gate_id": "dg_123",
"decision": "approved",
"comment": "Approved after validating the change ticket."
}
The agent would then continue from the suspended state with the approval result injected into the conversation/tool flow.
Why this may fit ds4
This seems aligned with ds4’s direction because:
- ds4 already supports native tool calling;
- ds4 already pays attention to exact tool-call replay and state continuity;
- local inference is especially attractive for enterprise and regulated environments;
- decision gates would not require ds4 to become a full workflow engine;
- the feature could be implemented as a minimal primitive, leaving policies and UI to external systems.
Minimal possible implementation
A first version could be intentionally small:
- Allow tools to be marked as requiring a decision gate.
- When such a tool call is generated, return a structured “gate required” event instead of treating it as a completed tool call.
- Persist enough session/KV/tool-call state to resume later.
- Add an API/CLI mechanism to resume the session with approved, rejected or modified.
- Include the gate decision in trace logs for auditability.
Non-goals
This proposal does not require ds4 to implement:
- a full approval workflow engine;
- user management;
- legal compliance logic;
- enterprise RBAC;
- policy authoring;
- a graphical approval UI.
The goal is only to expose a clean suspension/resume primitive that external systems can build on.
Use cases
- production deployment approval;
- financial or procurement workflows;
- customer data modification;
- medical, legal or HR decision support;
- industrial automation;
- regulated enterprise processes;
- multi-agent systems where one agent must approve another agent’s action.
Summary
A decision gate would make ds4 more useful as a local agent runtime for real enterprise workflows, where autonomy must be balanced with supervision, auditability and controlled execution.
I believe this could be a small but important primitive for moving local agents from coding/demo environments into core business and mission-critical processes.
First of all, thank you for the work on DwarfStar. I find the project especially interesting because it combines local inference, tool calling, KV state handling, server APIs and an integrated agent in a very focused way.
I would like to propose a feature that could make ds4-agent and ds4-server more suitable for enterprise, regulated and mission-critical use cases: decision gates.
Motivation
In many enterprise scenarios, agents are (or will) not only used to generate text or code, but to support or execute operational decisions: modifying production systems, approving business workflows, changing customer records, triggering financial actions, interacting with ERP/CRM systems, or executing actions that may have legal, safety, operational or compliance implications.
In those contexts, not every agent decision or tool call should be executed immediately. Some actions should be suspended and mediated by an external supervisor before the agent continues.
The supervisor could be:
This is also relevant for AI governance. For example, under the EU AI Act, high-risk AI systems must support effective human oversight. I am not suggesting that ds4 should implement legal compliance as such, but that a small technical primitive for supervised execution would make it much easier for downstream systems to implement these requirements.
Proposed concept
A decision gate would be a controlled suspension point in the agent execution flow.
When the model produces a tool call or decision that matches a configured gate policy, ds4 would not immediately execute or return it as a normal tool call. Instead, it would emit a structured approval request and preserve the agent/session state until an external decision is provided.
Possible decision outcomes:
approved: continue and execute / return the proposed action;
rejected: continue the agent with a rejection result;
modified: continue with externally modified arguments or instructions;
expired: continue or fail according to a timeout policy.
Example
A tool could be marked as requiring approval:
When the agent attempts to call it, ds4 could emit something like:
An external supervisor could then respond:
The agent would then continue from the suspended state with the approval result injected into the conversation/tool flow.
Why this may fit ds4
This seems aligned with ds4’s direction because:
Minimal possible implementation
A first version could be intentionally small:
Non-goals
This proposal does not require ds4 to implement:
The goal is only to expose a clean suspension/resume primitive that external systems can build on.
Use cases
Summary
A decision gate would make ds4 more useful as a local agent runtime for real enterprise workflows, where autonomy must be balanced with supervision, auditability and controlled execution.
I believe this could be a small but important primitive for moving local agents from coding/demo environments into core business and mission-critical processes.