Answers without the marketing. Wherever something depends on context or on the vendor — we say so directly.
We assume that any agent output may be wrong — so no output counts on its own. A task moves forward only when independent evidence exists: green tests, another agent's verdict pinned to the exact code revision, a matching CI result.
A hallucination that fails the tests will not pass the gate. A hallucination in the tests themselves is caught by a separate QA verdict and review. This does not eliminate errors entirely (no process does — including ones run by humans), but it turns "I trust the agent" into "I checked the evidence".
A human. Always. The process is built so that strategic decisions and acceptance of the result belong to the operator — an agent cannot close a task or merge a change into the main branch on its own.
The audit trail shows, for every change: who defined the goal, what evidence was collected, who accepted it. Accountability is assignable exactly as in a human team — just better documented.
Work stops at a gate with a named reason and a next owner — the process has no "quietly sitting idle" state. A blocked task goes back to the right stage or to a human, with a description of what is missing.
Returning work is a normal, designed move in the process — see the walkthrough demo, where verification sends work back for a fix.
Code fragments are sent to the model as part of requests — that is how every tool in this class works. What happens to that data next depends on the vendor and the contract: enterprise plans from the major vendors offer a commitment not to train on customer data, with zero or limited retention.
During adoption we match the vendor and mode (API, region, retention) to your requirements — including a policy for which repositories may be processed by agents at all.
Not by default. Agents work on isolated branches and working environments; secrets live outside their reach, and operations on environments go through the same gates as code. Merging into the main branch is done exclusively by a gate script once the evidence is complete — an agent has no permissions to bypass it.
We build this model on our own security product (VaultPAM) — privileged access management is our daily work, not an add-on.
You do — exactly the same as code written by employees. The work happens in your repositories, on your infrastructure or in an agreed environment. EUWarden claims no rights to the produced code and does not take the process away when the engagement ends.
That is the organization's decision, not the process's — but honestly: day-to-day work changes significantly. Less manual code writing and test execution, more task definition, review of agent work, technical decisions and verification design.
In practice the bottleneck stops being the number of hands and becomes the number of people who can define a goal well and judge the result. Reskilling the team is part of the adoption path.
Two main components: model cost (token fees — driven by volume and task class) and the cost of people in new roles (operators, subject-matter oversight). Plus existing infrastructure: CI, repositories, issue tracker.
The math only makes sense against a baseline: that is why the pilot measures cost per delivered change and compares it with the status quo. We do not promise a multiplier before measuring — you get numbers from your own organization after the pilot.
Not at the start. The operator needs to understand the business goal and be able to judge the result — not to prompt. Engineers learn to work with agents during the pilot, on their own tasks, with assistance. AI competence is built along the way, not up front.
With a readiness assessment — 2–3 weeks reviewing repositories, workflow, people and tools, without changing anything. The result: a readiness report and a selected work stream for the pilot, with the go/no-go decision on your side.
Details of the three phases: adoption path. First step: michal@euwarden.com.
The process is language-agnostic — it requires a git repository, an issue tracker and a CI capable of running tests. The quality of agent work depends on the quality of feedback signals in the stack (tests, types, lint) — we assess this in the readiness phase and say plainly what needs strengthening first.
Our examples show Jira and GitHub because that is what we run on. What binds, however, is the capability contract, not the product name: the tracker needs configurable statuses and transitions, labels, and an API for comments and transitions; the code host needs pull/merge requests, required check statuses, and an API. GitLab, Linear and Azure DevOps Boards meet this, among others. We verify the fit in the readiness phase — and say plainly if something is missing.