Reference architecture
Every workflow becomes a scene: its data, its tools, the agent that runs it, and the history of everything it did. This page is the picture an architect draws before signing off: what the scene may touch, where a write stops, what is recorded, and where it all runs.
Three boundaries, and only people cross the first one
People and their surfaces on top. The scene in the middle, with the gate a write has to pass and the history it lands in. Your systems and your machines below, and under them the network, which a machine can lose. The three boundaries are the whole security model, and the rest of this page walks them.
A scene is the unit you govern
An agent does not get your landscape. It gets a scene: the accounts and documents pinned into it, the people and agents who are members, and the roles each of them holds. An account that is not in the scene is not reachable from it, and a member's role decides what they can pin, run and approve.
A person is a passkey on a device they enrolled, and an agent acts under a grant a person gave it. Revoking a device ends its sessions the same minute, and the approval a person gave is signed by the key that gave it. Identity has the details.
Inside the scene, what people see is layered. A cell can be private to its author, shared with the team, or published to a link. The same rule covers an agent's output, so a draft stays a draft until someone moves it. Scenes and layers have their own pages.
Writes that matter wait for your approval
A read runs. A write does not: the call is staged with its exact inputs, the person sees what would change, and the job pauses until they approve, reject or edit it. On Microsoft 365 every write is gated this way. On S/4HANA the calls that change something stop and ask. The rule has no exceptions by provider, so a mail send, a calendar event and a purchase order sit behind the same gate.
Autonomy is something you grant, not something the agent takes. A scene can carry always-allow rules for named tools, or auto-approve for a whole scene or a single job, and both are visible in the scene's settings. A call that runs under a rule is recorded like any other. The gate has its own page.
Every step is recorded, with who approved it and what it cost
A job's history is the prompt, every tool call with its inputs and outputs, the approvals and rejections with the person who made them, and the cost of each model call. It is the same record whether the job ran from the app, from Teams, from the command line or on a schedule at three in the morning. When an auditor asks why an email went out, the answer is a job, not a search through logs.
The history is a chain: each step names the one before it by content, so altering any step breaks every step after it. A record can be read, exported and verified, and it cannot be quietly edited. Traces, audit and the commit chain go deeper.
Reads go through the account you connected, and nothing else
Each integration is connected under its own consent: an OAuth app in your name, an API key you issued, or a technical user your admin created. Daslab reaches a system exactly as that identity and no further. For Microsoft 365, one Entra app and one admin consent cover Teams, Outlook, OneDrive, SharePoint and Power BI, and Daslab holds no scope for private chats.
Next to SAP, a customer can run an in-network node: a read-only copy of the ERP fed through the standard data-preview path, so no database user or database port exists to expose, and the node only ever connects outbound. Questions the source cannot answer in one statement, a whole-population ranking say, run against the copy and reconcile back to the source.
A scene can run on hardware you own
One command on a Raspberry Pi, a Mac mini or a Jetson joins it to your workspace, and a code on your phone confirms it is yours. Scenes you pin to that machine run there: on your network, from your address, next to what you plugged in.
What you plug in is published on the machine's tile: a camera, a robot arm, a sensor board, a printer. A scene pinned to the machine can use them, and the agent is told what is there. The same scene can hold your S/4HANA account, so the person who reads a gauge and the system that carries the order are in one job. The machines and how a node joins have their own pages.
IP · 1080pcamera
6 joints, usb-serialarm
ESP32 · temperature, vibrationsensors
A machine keeps working when the network does not
A depot without a link, a ship, a plant whose uplink drops for an afternoon: a scene pinned to a machine there does not stop. The machine commits each step locally, in the same history format the workspace keeps, and signs each commit with a key that never leaves the device. When the link returns, the two sides compare their last commits, find the common ancestor and exchange only the difference. No clock has to agree, because order is structural, each commit naming its parent. A step taken offline arrives with its signature, so what happened on the floor is as verifiable as what happened on the server.
From the workspace's side, a machine that is away shows as away and the steps that need it wait. From the machine's side, nothing waited. When both sides changed the same thing, the history shows both and the merge is a visible step, not a silent overwrite.
Your model contracts, under their terms
The model is a field on the agent, not a property of the platform. Bring your own keys for Anthropic, OpenAI, AWS Bedrock, SAP AI Core, Gemini or OpenRouter, and the scene's jobs run on that contract, under its data terms. For a scene that must not leave the building, the model can be one running on a machine you own, a Mac mini on Apple silicon say, and a scene pinned to that machine sends nothing out. Daslab does not train on your data. Letting Daslab pick the model per turn is a switch you turn on, off by default. What model usage costs is on the pricing page.
The cap is checked before the call, not on the invoice
A scene, an agent and a billing period each carry a hard limit. The check happens before a model call is made, so a runaway job stops at the cap rather than showing up as an overage. Allowance is prepaid and topped up on purpose; there is no invoice for what you did not intend.
On our cloud, or one binary on your servers
The cloud runs the same software we hand to self-hosted customers: one process, your database, your object storage, your model keys, your domain. There is no cluster to operate, and the accounts you register in your name take longer than the install. Self-hosting is part of the Enterprise plan. The security page lists what runs where, and the DPA and the sub-processors sit next to it.
The scene maps onto the architecture language you already use
If your architecture lives in an ArchiMate repository, a scene's current state can be exported in the Model Exchange File Format and opened there. The mapping is fixed, so the model your architects hold is generated from the scene rather than drawn next to it.
| In Daslab | In your model | Joined by |
|---|---|---|
| A scene | Grouping | aggregates everything below it |
| A connected account | Application Interface | composed by the system's Application Component |
| A tool the agent used | Application Function | assigned to its system, serving the process |
| A job | Business Process | served by the functions it called, in order |
| A machine, a device | Node, Device, Equipment | serving the system that talks to it |
| An approval rule | Constraint | associated with the function it governs |
| A member | Business Actor and Role | assigned to the processes they run or approve |
What an architecture review asks
Can the agent act without a person? Where you have allowed it: an always-allow rule for a named tool, or auto-approve on a scene or a job. Everything else waits. Every call, allowed or approved, is in the history.
What leaves our network? The prompt and the data the job reads go to the model contract you chose, under its terms. With an in-network node, nothing connects inbound, and the ERP copy stays on your side. With a local model on a machine you own, a scene pinned there sends nothing out at all.
Can we run all of it on our side? Yes. One binary, your database, your domain, your model on Bedrock, SAP AI Core or your own hardware. It is the same software as the cloud, operated by you.
Does it learn from our data? No. Daslab does not train on your data, and the model contract you bring carries its own terms.
What happens when a machine is offline? A scene pinned to it keeps running there and commits locally, signed. The workspace shows the machine as away and the steps that need it wait. When the link returns, the two histories merge by ancestry and every offline step arrives with its signature.
Can the history be edited after the fact? No. Each step names the one before it by content, so a changed step breaks the chain after it, and the check is something your auditor can run.
Who can see a job? Members of its scene, by role. A cell made from it is private, shared or public by the layer it sits in.
See it on your system
Bring the landscape you have to sign off on. We connect one scene to it and walk the two boundaries with your architect on the call. Get a demo, or read Daslab on SAP first.
Updated 2026-09-09