Until now: waiting for the report.
Shift supervisors only find out on Friday which orders are running late. The information sits in the ERP, but isn’t available when it’s needed.
Working with AI. As a team.
Baden AG · Swiss German region
Individuals got faster. The team hasn’t.
We help your team understand what AI, language models and agents can do — and put them to use in everyday work.
Together we work out which tasks agents can take on, how results get checked, and where people decide. We work this way ourselves — and we put it into practice with your team: in software development, IT operations and business processes.
Start a conversation15 minutes · no obligation · free
What that looks like in practice
Software development · Infrastructure & operations · Business processes
01 / Does this sound familiar?
The AI tools are in place, but good ideas keep getting buried under day-to-day work.
Your people produce more, yet still spend a lot of time searching, aligning and checking.
What individuals have learned hasn’t become a shared way of working yet.
02 / How that becomes practice
From brief to
tested application.
Sometimes an improvement starts with a question that has been sitting around for a long time. AI can help build the right software with less effort. Or it takes on tasks within a running process itself. In the shop-floor display below it helps with the building; the finished display needs no language model at all.
New way of working: building with agents.
A clear brief guides the development of a focused display. Agents help with code and tests; people settle the data, the behaviour and the sign-off. The finished display needs no language model of its own.
Goal: being able to decide sooner.
Shift supervisors should start the morning with a current overview. The value lies in reacting to delays earlier — not in the amount of code produced.
Drawn from a real project: names and figures have been changed, and the brief has been extended with acceptance criteria for this write-up. What matters here is the way of working and what came out of it.
Shift supervisors see delays in the morning, not on Friday.
- What should get better
- Today, shift supervisors only learn on Friday which orders are late. They should see it every morning at six, without having to ask anyone.
- How you can tell
- The display shows open overdue orders and those due within the next five working days, overdue ones first. Orders with no due date are listed separately. Figures and counts match the ERP. If the query fails, the display says so clearly and never presents stale data as current.
- What is out of scope
- No root-cause analysis, no notifications, no second screen for management. That comes later, or never.
- What the development agent may do
- Read approved ERP data, work on code and tests within the scoped project, and run tests in the test environment. ERP write access and permission changes are excluded. Releasing to production is approved separately.
- How we check
- Selected orders are reconciled against the ERP. Tests cover overdue, due-soon and undated orders as well as an ERP outage. Shift supervisors first run the display alongside the existing report. It replaces the report only after sign-off from the people who use it.
- What we learned
- The delivery date in the ERP was unmaintained on a third of all orders. That — not the display — was the real problem. The brief gained a paragraph about it, the display a line reading “date missing”.
What matters in this example is the moment the data contradicts our idea. That is when we listen more closely and change the brief. The work shows us what is still missing.
# specs/shopfloor-display-late-orders.md intent: Shift supervisors see delays at 06:00, without asking. acceptance: - Open overdue orders + due within the next 5 working days - Overdue first; missing due dates listed separately - Figures and counts match the ERP - ERP timeout → explicit error state; never show stale data as current out_of_scope: - Root-cause analysis, notifications, second screen for management development_agent: read: [project_docs, approved_erp_orders] write: [workspace_code, workspace_tests] execute: [tests_in_isolated_environment] deny: [erp_write, change_acl, send_messages, production_deploy] release: requires: [technical_checks, domain_acceptance, human_approval] evals: - domain: overdue, due_soon, missing_due_date, count_matches_erp - failure: erp_unavailable → explicit_error_status - hand_check: reconcile selected orders against the ERP - rollout: run alongside the old report, then domain sign-off learning: - 1/3 of due dates unmaintained → spec += “date missing”
- Software development
AI helps with the building. Custom applications and changes can become feasible with less implementation effort. We work out with your team which of them carry the most value, and stay with the work through to sign-off.
- Business processes
AI works inside the process. An agent can bring an enquiry together with customer history and the relevant knowledge. Support starts from a prepared case and concentrates on judgement and resolution.
- Infrastructure & operations
AI supports decisions and actions. An agent can combine logs, changes and operational knowledge into a reasoned assessment. Automatic interventions require appropriate permissions, sufficient checks, and a safe path to fail or roll back.
How checking keeps pace with the building
When more changes appear, checking needs evidence to match. We keep changes small and combine:
- Tests for formats, rules, interfaces and everything that already worked.
- Domain test cases from everyday work, including unclear inputs and expected failures.
- Targeted reviews for architecture, behaviour and security. Scope and depth follow the risk and any existing requirements.
- In operation, fixes turn into new tests.
An agent vouching for its own output is not evidence. For clearly bounded changes an automatic release can make sense — where independently checked criteria, permissions and error handling can carry it.
Who is responsible for what?
Not four new roles to hire. In a small team, one person often covers two of them.
- Brief
- The domain and IT write down what should get better. And what shouldn’t.
- Delivery
- The team owns architecture and integration. Agents take on tasks within access and execution limits enforced technically, not by convention.
- Release
- Named owners judge the evidence. For automatic releases they set the criteria and limits in advance; critical changes get looked at deliberately.
- Operations
- Someone watches for faults, keeps the tests current, and decides when the process itself needs to change.
Workshop / nerd mode
The same thing,
for developers.
Above, the brief in plain language. Here, how it lands in a repo and in CI.
Evidence instead of blanket approval
- CI: formatting, schema, existing tests, permitted paths
- Domain-confirmed test cases; tests written by the same agent are not independent evidence
- Reviews by risk and type of change; a failing required check stops the release
- On failure: trace the relevant inputs, context, tool calls, results and system state — with due care for sensitive data
What lives in the repo
- spec.md — goal, limits, acceptance, and pointers to the authoritative sources
- evals/ — test cases with expected results and defined release criteria
- policy — permitted access and actions, enforced through runtime and permissions; secrets managed separately
- learnings — findings change the brief, the tests or the source that owns the knowledge; wiki, tickets and repo stay linked
What we work with ourselves
We work with agent-assisted development environments, connected knowledge sources and automated checks. Whether models and tools run in the cloud, on your own infrastructure or both depends on data, permissions, capability and what it costs to operate. Where existing components fit, we keep them.
How the work divides
Work is divided along what people and agents are each good at:
- People agree the value and the limits, agents handle bounded tasks, the team judges the results
- Checking and release match the risk; what operations teaches us improves the brief, the context and the tests
03 / How we work with you
We build with
your team.
A good idea is often still out of focus at the start. We take the time to understand it with the people who will work with it. And stay close enough to build it with them.
-
Listen first.
We listen to the domain, to IT and to suppliers. What are people trying to achieve? What do they know that appears in no ticket? Where does time go — in handovers, dependencies, or knowledge nobody wrote down? We connect that experience with what AI can do, and find the point where something can actually get better.
-
Make room to try things.
We take one manageable task and settle the goal, the limits and the checks. In a safe environment we find out what people and agents can do together that neither finds easy alone. Then we build the next useful step with your team — down into the code and the interfaces.
-
Let the work speak.
Everyday use shows what holds. We look together at the result, the effort, and the places where it still catches. We simplify, improve, or drop something again. With each round, the team’s own judgement grows about where AI genuinely helps.
04 / Getting started
Start with
a specific project.
You don’t need a finished use case to begin. An idea, a recurring annoyance, or a task there is never time for is enough. Together we turn it into a manageable piece of work with a clear result.
Typical shape: 6–8 weeks · scope, prerequisites and acceptance agreed up front
Something that helps day to day.
The agreed solution is built and checked against realistic cases. What it needs to run, and what limits remain, is written down.
You can decide.
You see what is newly possible, and how effort, quality and rework change. That is something you can decide on: extend, adjust, or stop.
Your team can carry on.
Briefs, tests, access rules and knowledge stay with you. Just as important: your team has learned to ask good questions itself, to check results, and to shape the next step. Who looks after the process is settled.
One concrete problem, people from the domain and from IT, and a few examples make a good start. We work out the right application and the prerequisites together.
Discuss a starting pointIf you need longer-term support or a second opinion
Ongoing: one to two days a week, three months to begin with. Goals, priorities, suppliers, delivery — at one table, close to the code.
One project: a new interface, something on the shop floor, an old system that needs to go. From brief to sign-off. Effort agreed beforehand.
Second opinion: we review a quote, a system choice, or a proposal from your team. You get a reasoned assessment of value, risks and alternatives. In writing and in conversation, at a price agreed in advance.
05 / About dezent digital
We work with
agents ourselves.
We build software that makes people’s work easier.
dezent digital works from Baden with companies across the Swiss German region. We combine AI expertise with experience in software development, infrastructure, and the processes between people and business systems.
Since 2024, agents have written the bulk of our code. We try things, check them, discard them, and keep learning. That practice of our own shapes the questions we take on with your team.
We don’t need to predict the whole future to find a good next step. What interests us is how people can use these new tools to realise more of what matters to them.
Maybe it starts with “what if …?”
What should your team
be able to do?
Tell us what you would like to make possible. Or what holds your people up needlessly every day. We’ll listen, and look for a good starting point with you.
Start a conversation
15 minutes · no obligation · free