Skip to content
DEENRequest an intro call

AI Engineering, GRADbuild

AI that works in everyday business.

We design the solution architecture and build assistants, automations and process agents that run in your environment, are accepted on your own cases and are handed over to your IT.

Autonomy levels

How much autonomy a process can bear.

Five levels, from assistant to a team of agents. Every added level of autonomy demands more measurement, more safeguards and an organisation that keeps up.

The human leads every step, the AI delivers drafts.

The AI assists, the human approves every result.

A fixed chain with checkpoints.

A goal instead of a script: the AI plans on its own.

Specialised agents coordinate.

More autonomy

More oversight needed

More trust to lose

What this level demands: Assistant
The systemAnswers, no tools.
The humanDecides everything.
Strictly requiredGround rules, prompting guide.
ExampleFAQ assistant.

Most applications can be run responsibly between Copilot and Agent today. Assistants operate at the Assistant and Copilot levels, automations as Workflow, process agents as Agent.

Technologies and patterns

What we build with.

State machineEvery step explicit, traceable, resumable.
Workflows and approval formsSelf-hosted, you see the flow.
System connections as MCP serversReads freely, writes only with approval.
MemoryWith tenant separation.
Model gatewayRouting per task and budget. No use for training; data retention at the provider contractually limited to the minimum.
ObservabilityTracing and cost per case.
GuardrailsContent from documents and emails is data, never commands.
Eval harnessRegression on every model change.
Secrets and permissionsLeast privilege, separate secrets, token scope per system connection.
Data protectionSwiss FADP and GDPR with a data processing agreement, pseudonymisation, defined retention and deletion, data location in Switzerland or the EU.
Outage and fallbackDefined degradation and fallback path, latency and error-rate thresholds with escalation.
charter.yaml, samplename: invoice_review
level: 03 Workflow
goal: match incoming invoices against the order
may: read erp.orders, read mail.inbox,
  write erp.approval_draft
may_not: payments.execute, masterdata.change
secrets: identity per connection, token scoped to need
approval: human on deviation or above threshold
escalation: accounting, within one business day
outage: manual review as fallback, alert above threshold
proof: acceptance on the test set against target values
log: every step in the audit log, cost per case

The framework is replaceable, the principles are not: explicit state, one module per permission, verification before effect, approvals as data, everything logged, everything measurable.

Patterns we build in

Answer verification with a second model, confidence routing, autonomy as a policy per action, eval regression as a job.
System connections with approval tokens, agent-to-agent for partner systems, legacy bridge, technical identities per module.

Solution architecture

What runs where.

The target architecture is designed for your existing IT landscape: interfaces, identities, data flows and model choice. GRADbuild always follows the same pattern.

Your environment
GRADbuild as a container
Models

only with a contract

State machine

Every case has an explicit state. Abort and restart are designed in.

Deployment and sovereignty

You decide where your data and models run.

Four options

  1. 01Swiss provider, your account
    What runs where
    Swiss data centres, models via Swiss providers
    For whom
    Companies without their own cloud infrastructure, high demands on data location
  2. 02Hyperscaler in the Swiss region, your tenant
    What runs where
    Swiss region, frontier models, sign-in via your identities
    For whom
    Companies with an existing hyperscaler tenant and their own IT
  3. 03On-premises or colocation
    What runs where
    Servers at your site, open models, your IT operates
    For whom
    Explicit requirement that nothing leaves the building
  4. 04Hybrid
    What runs where
    Data and cockpit at your site, models via the Swiss region with pseudonymisation
    For whom
    Personal data that must not reach the models

Six questions to decide

Prerequisites

Is there an IT team that operates infrastructure?

Is there hardware and an IT team for on-premises?

Should personal data in clear text never touch a US provider, even in the Swiss region?

Preferences

Do you already have a tenant with a hyperscaler?

Does the solution need frontier quality?

Should nothing leave the building, not even pseudonymised data?

All four options remain open.

Applies to all optionsAccount, data, configuration and logs belong to you. For companies in the EU the same four options apply with providers and regions in the EU.

How a project runs

Five gates, no shortcuts.

Process: five gates

  1. G0Kickoff with charter, access and contract.
  2. G1Test set from real cases.
  3. G2Acceptance on the test set against target values.
  4. G3Go-live after trial operation.
  5. G4Handover with runbook, open-items list and deletion record.
Measurement: four KPIs
KPIMeasured by
Automation rateShare without human involvement
Error rate on critical fieldsTest set and spot checks
Lead timeTimestamps per case
Security violationsAudit log and alerting
PrincipleTarget values are never lowered to pass an acceptance. Larger programmes pass through the gates for each expansion step.

For your IT

What your IT asks before the decision.

Integrations by testing status
Proven, included in every pilotMicrosoft 365 with SharePoint, Exchange, Teams and Entra ID, ticket systems such as Zendesk, Freshdesk and Jira Service Management, bexio, mailboxes, SFTP, scanner folders and portals.
Via file or after an integration testAbacus, Microsoft Dynamics 365 Business Central, Opacc.
Only after a test day on the real systemPROFFIX, other industry software, systems without an interface via the legacy bridge.
For every system outside this list, an integration test precedes the pilot: one day on the real system, reading and writing, with a short report.
Identities, logs, export and exit
IdentitiesEvery module has its own technical identity and only the permissions it needs. A document recognition module has read rights only; a handover module may only create new records.
LogsEvery action sits immutably in the audit log, with timestamps and cost per case.
ExportLogs, test sets, rules and configuration can be exported at any time, in open formats.
ExitThe handover to your IT includes runbook, usage rights, open-items list and deletion record. No lock-in.
Security fact sheet

Data location, identities and access, encryption, immutable audit log with export, protection against prompt injection, network, continuity. One page for your IT management and information security, on request. It does not replace a certificate, but it answers the questions that otherwise delay vendor due diligence.

Engagement by starting point
Without an in-house IT departmentSolution in your account with a Swiss provider, handed over to you or your IT partner.
With your own ITAutomations and process agents in your own tenant, with security fact sheet and log export.
Large enterprises and groupsSolution architecture and implementation within your existing platform, identity and security landscape, together with your IT and your suppliers. The autonomy levels serve as a shared governance framework across several initiatives.
Regulated industriesRequirements from supervisory authorities, data protection and industry rules are built into charter, architecture and acceptance from the kickoff.

The next step

Which level fits your process?

In the intro call we settle process, data situation and the level that pays off.

Request an intro callContinue to AI Governance