Tool · Build

Workbench

The Workbench is where developers build with coding agents on real projects, on your own infrastructure. It turns a ticket into a plan, runs agents in isolated workspaces, and keeps a person in control of every result.

The ESACA Context Builder: the Coding step, with the requirements-to-review workflow and a subtask dependency graph.
The Context Builder: from requirements to review, with subtasks and their dependencies.

Capabilities

From a ticket to reviewed, working code

01

Plan from a ticket

Turn a ticket or an intent into an implementation plan and break it down into concrete subtasks before any code is written.

02

Multi-agent orchestration

Run several coding agents in defined workflows, each handling part of the work, instead of one agent doing everything at once.

03

Pluggable agents

Works with OpenCode, Claude Code, Aider and CLI-based agents, so teams are not locked into a single agent runtime.

04

Multi-repo, pinned state

Work across several repositories at known, pinned commits, so a task is well defined and the result is reproducible.

05

Isolated execution

Each agent works inside an isolated, sandboxed workspace rather than loose on the host, so it only touches what it is meant to.

06

Human-in-the-loop, binding

A person stays in control. Agents can propose and mark work done, but the human keeps the override and the review stays binding.

07

Fits your development flow

Designed to sit alongside your existing Bitbucket and GitLab workflow, with an audit trail of every agent action.

08

Bring your chosen model

Use the model you selected in the Benchmark. Switch models without rewriting endpoints, on self-hosted or cloud compute.

Security · Harness Security

The model suggests. The harness decides.

A coding agent is more than a model. Around it sits the harness: the instructions it starts with, the tools it may call, the rules that approve or block each call, the context it loads and the agents it hands work to. Whoever controls the harness controls the agent – so that is where we put security. Rights are granted per task step and enforced by deterministic checks the model cannot argue with. Everything the agent reads – tickets, READMEs, dependency docs – is treated as data, not orders. And when several agents work together, each gets its own workspace, its own rights and an independent reviewer.

The harness as concentric rings around the model: instructions, tools and rights, policy hooks, context and skills. Tool calls must pass the policy ring; a repository file trying to override the rules is rejected. MODEL proposes CONTEXT & SKILLS · managed POLICY HOOKS · decide TOOLS & RIGHTS INSTRUCTIONS ✓ edit src/app.ts ✕ git push --force README.md “ignore your rules …” rejected at the outer ring The model suggests. The harness decides.
Every tool call the model proposes has to pass the policy ring. Text in a repository can’t talk its way through.

01

Managed harness

Whoever controls the harness controls the agent.

  • Tool rights per task step, not per session
  • Policies run as code before and after every tool call
  • Instructions, skills and memory only from the approved configuration
  • Harness versioned, reviewed and recorded with every run

02

Data, not orders

Your agent reads everything. So does your attacker’s text.

  • Every input classified: trusted, internal or external
  • External content fenced and labelled before it reaches the model
  • Least privilege and default-deny egress limit the blast radius
  • Plan review catches a hijacked step before any code is written

03

Zero trust between agents

More agents, more doors. Each one gets its own key.

  • Separate workspace and rights per agent
  • Handovers as validated artifacts, not free-text orders
  • Independent reviewer: own context, ideally another model
  • Every hand-off logged: who produced what, from which input

Security · Gates, identity and review

Every change is checked, has a name, and gets a real review.

Agents produce code faster than any security team can read it. So the checks move into the loop: every agent step runs through the gates your pipeline would apply later, and the agent fixes findings before a person sees the diff. Every change carries the identity of the agent, the model and the person behind it. And because a human in the loop only helps if the human can still see, we design review for real attention: small diffs, risk-based routing and reviewers who know what AI-written code gets wrong.

The Workbench loop Ticket, Plan, Agents, Review, Handover, with a security gate between Agents and Review that sends findings back to the agents. Each commit is signed and attributed to agent, model, harness and responsible person. Ticket Plan Agents Review Handover security gate: SAST · SCA · licences · secrets findings back first COMMIT 8F3A2C1 · SIGNED ✓ agent: coder-2 model: model-x 2026.09 harness: wb-policy v14 on behalf: J. Doe own identity per agent – no shared tokens
Checks inside the loop, and every commit signed and attributed.

01

Gates and identity

Every change is checked. Every change has a name.

  • SAST, SCA, licence and secret scans after each step, not only in CI
  • Findings go back to the agent first; people review clean diffs
  • Own technical identity per agent – no shared developer tokens
  • Commits signed with agent, model, harness version and responsible person

02

Review that stays effective

A human in the loop only helps if the human can still see.

  • One subtask, one small diff
  • Changes to auth, secrets, dependencies or CI go to a security-aware approver
  • Requirement → plan step → agent → diff, visible at review time
  • Reviewer training on AI failure patterns, including invented packages

Workbench · Positioning

For whom — and why

Not a speed tool for vibe coders, but the controlled entry into agentic development — especially with on-premise models.

01 — Beginners

Guided by the hand

Training wheels for getting started with AI — especially with on-premise models, where context and steering are more demanding. It tends to slow the hardcore vibe coder down.

02 — Enterprises

Processes baked in

Good software engineering — traceability, tests before implementation, quality gates, templates — becomes part of the AI process instead of the wild west.

03 — Compliance

Auditable & KRITIS-safe

Full audit trail, managed context instead of uncontrolled on-the-fly loading of skills or plugins — AI hacking is contained, teams work in a standardized way.

How it looks

A loop, not a one-shot

1

Ticket

Start from a ticket or an idea.

2

Plan

Plan and decompose it into subtasks.

3

Agents

Agents work in isolated workspaces.

4

Review

Review the result, with a full audit trail.

5

Handover

Hand over to your normal review and merge.

What it gives you

Agentic speed, without giving up control

Developers stay on real projects instead of throwaway sandboxes.
Code and context stay on your own infrastructure.
Every agent action is logged for review and audit.
It is part of the development flow, not an isolated one-shot.

Traceability & quality, built in

The Workbench bakes testing, quality assurance and traceability into the development process itself. An optimised agentic workflow produces results on your own on-premises models — tested as they are built, and traceable through every agent step back to the original requirements and specifications.

The approach

Three pillars of sovereign coding

01

Air-gapped appliance

Runs fully offline inside your own data centre. No data egress, no external API calls, no hidden telemetry channel.

02

Sovereign models

European LLMs on your own hardware. Updates via a controlled supply chain: you decide what is rolled out, and when.

03

Audit-ready by design

A full audit trail of every agent action. RBAC, SSO and SIEM integration address NIS-2, ISO 27001, GDPR and BaFin requirements.

Kontakt aufnehmen


An initiative by
mgm technology partners Fsas Technologies, a Fujitsu company