Dromni Logo

Technology

The principle: a layer between people and AI agents

DAOS is not a chat program and not a model. It is a layer that sits between your employees and the AI agents: a service installed on your own machines and servers, running in the background and automatically taking over the management of the agents when the system starts.

The value of that position is simple: every request has to pass through this layer – on the local machine too. Which means rules can be enforced, costs measured, and evidence produced at exactly one place – for all agents, all models, and all employees at once. DAOS is operated through an interface in the browser that runs on the local machine, or from the command line; neither needs a connection to the outside world.

The path of a request

Request → Rule check → Model choice → Execution → Response → Log entry
1

Request

2

Rule check

3

Model choice

4

Execution

5

Response

6

Log entry

Illustrative path – the detailed walkthrough is below.

  1. 1

    Someone submits a task

    An employee asks an agent to summarise a contract – through the DAOS interface or a tool connected to DAOS. Not directly with a model provider.

  2. 2

    DAOS checks the rules

    Before anything happens: may this role start this agent? Which models are approved for it? Is the budget for this period still open? A rejected request is rejected – not silently rerouted.

  3. 3

    DAOS picks the model

    Only then does DAOS decide who takes the task: a local model on your own network for routine work, a frontier model in the cloud only when the task demands it – and only if the security tier of the data and of the context allows it.

  4. 4

    The agent works sealed off

    The agent runs in its own container with fixed limits on compute time, memory, and storage. Databases and files are granted to it individually and on request. It cannot call a model provider by itself.

  5. 5

    Everything relevant is logged

    Every model call, every resource access, and every policy decision produces an entry with timestamp, cost, and outcome. A missing entry counts as an error, not as normal operation.

Where your data stays

Every resource and every body of data in DAOS carries a security tier, which you are free to choose per resource. It decides how far the data may travel: Public and Confidential may be passed on to an external model provider, while Strictly Confidential, Secret, and Private stay entirely inside DAOS and are processed there by local models.

Without DAOS

Employees exchange data with each other; only occasionally does even highly sensitive data slip straight to the LLM provider, uncontrolled.
Your employees
LLM provider

With DAOS

The DAOS server sits between the machines, receives their data, and forwards only Public and Confidential data on to the LLM provider. Strictly Confidential, Secret, and Private all stay entirely within DAOS.
D
D
D
D
D
Your employees
LLM provider
DAOS

Security tiers

PublicConfidentialStrictly ConfidentialSecretPrivate

Illustrative representation – not a real system architecture.

Two details make the difference: the boundary is technical, not organisational – an agent has no route of its own to the outside, every model call goes through DAOS. And the classification lives on the resource, not in the user's head: someone who does not know how sensitive a file is cannot accidentally send it to the wrong model.

The five building blocks in detail

Monitoring

  • A dashboard in the browser shows more than 20 metrics in real time: processor load, memory, disk, network, and – where present – the graphics card including temperature, utilisation, and memory usage.
  • At process level it is visible which agent consumes what. Not "the system is slow", but "this agent is occupying three cores right now".
  • Alerts in five severity levels with configurable thresholds (defaults: 80 % processor load, 85 % memory, 90 % disk).
  • A 24-hour metrics history makes trends and capacity needs visible.

Resources registry

  • At startup, DAOS discovers for itself what is available: hardware, the container runtime, locally installed models, connected interfaces, databases, and network services.
  • Every resource is registered and tagged with a security tier. The registry therefore also answers the question of which AI-relevant resources exist in the company at all.
  • An agent does not receive resources wholesale but individually and on request – every grant and every release is logged.
  • The registry can be searched by type, security tier, or availability.

Policies

  • Three levels: the system level applies to everyone and is immutable, the user level governs roles and departments, the local level governs individual workloads. The system level takes precedence – local rules cannot water it down.
  • Approval lists for models take effect in real time: an unapproved model is blocked at call time, not flagged afterwards.
  • Role-based permissions define who may start agents, change policies, or view logs.
  • Templates exist for development, production, and regulated environments. Every change to a policy is logged and therefore auditable.

Cost and testing

  • Costs are captured per agent and per individual model call: compute time, memory, calls, network, and storage.
  • Every call comes with a log entry – which model, which task, which cost.
  • Budgets can be set per hour, day, week, or month. Warnings fire at 50, 75, 90, and 100 percent; beyond that there are four responses to choose from: warn only, pause the agent, stop the agent, or block new operations.
  • A cheaper model can be tested against the incumbent during live operation, before you switch.

Agent runtime

  • Create, start, stop, restart, remove – the entire lifecycle through one interface.
  • Every agent runs in its own container. A faulty agent does not take any other one down with it. After a failure the system is operational again within minutes.
  • Limits on processor cores, memory, and storage can be set per agent individually. The agent works in a closed system and can therefore be operated safely.
  • After a failure an agent restarts automatically, with increasing waiting times between attempts. A health check reports outages, and a standby mode releases the resources of idle agents.

Connecting and switching providers

DAOS talks to local models via Ollama and to OpenAI, Anthropic, and Google Vertex AI. On top of that, any provider offering an OpenAI-compatible interface can be connected – by now the industry standard.

What matters is that all providers sit behind one shared interface. A provider can therefore be switched, added, or disabled at any time, without code changes, without data migration, and without a system outage.

Provider credentials are stored encrypted in the operating system's keychain – not in configuration files and not in environment variables. An employee never needs to see the company key in order to work with the model.

How evidence is produced

A user writes a prompt that goes to the AI agent. The agent processes the request and writes traces to an audit database. The database is analyzed and produces a report for the risk analysis. The risk analysis derives a policy proposal from it that adjusts the user's settings – closing the loop, which then starts again.
User
AI agent
Audit database
Risk analysis

Illustrative representation – not a real data flow.

In DAOS, logs are not a report someone writes at the end of the quarter but a by-product of operation. Every crossing of a boundary produces an entry: a task coming in, a model call, a resource access, a policy decision, a start or a stop.

  • For every model call, request and response are stored encrypted – exactly the logging that Article 12 of the EU AI Act requires.
  • Entries cannot be altered once written. Gaps and after-the-fact interference are detectable, not merely unlikely.
  • Retention: six months directly accessible, and with our service up to five years in the archive beyond that.
  • Changes to policies land in the log as well. Who relaxed which rule and when therefore has an answer.

Next up: the technical specification for requirements, models, and encryption – or go straight to installation and start.