How it works

Seven stages, two graphs, six places it stops.

Teqys is not a chat that writes snippets. It is a durable workflow: documents drafted and criticised before you see them, then delivery agents that write and verify real code, with approvals wired into the workflow rather than layered over it.

From a conversation to a deployment

Each stage feeds the next from the approved version of what came before, not from a draft that happened to be lying around.

  1. Discovery

    A conversation becomes structured notes

    Run a discovery session live or paste the transcript. The meeting agent captures what was said and asks a capped number of clarifying questions. It does not invent a product out of hallway talk, and later meetings stay inert until someone accepts them.

  2. Specification

    A business analyst drafts the BRD

    Stakeholders, scope, requirements and acceptance language, written so a client can argue with it. A product critic reads the draft and returns a structured verdict; a failing verdict goes back into the drafting node with the required changes attached.

    You approve the BRD before anything is designed

  3. Design

    Architecture, then the technical requirements

    The system shape comes first — components, data flows, interfaces, constraints — and a lead critic revises it before you ever see it. The TRD follows from the approved architecture rather than being written alongside it.

    Architecture and TRD are two separate approvals

  4. Plan

    An implementation plan a non-engineer can read

    Work breakdown, delivery order and the risks named in language that does not assume a compiler. This is the last cheap moment to disagree, which is exactly why it is a gate.

    Nothing irreversible happens until this clears

  5. Build

    Specialists write real files in a sandbox

    Data model, screens, backend, frontend. Each coding agent runs a plan, act and reflect loop against a contained workspace, writing real files and running real commands to check them — not describing what it would write.

  6. Verify

    Tests that ran, not tests that were imagined

    QA executes the suite and reports exit codes. A failure routes back to coding with the finding in context rather than being noted and passed on. Security review works the same way, and a blocking finding stops the run.

  7. Ship

    Your GitHub, your branch protection

    Code lands as a pull request in your organisation from the first commit, so there is no export step and nothing to hand over. Opening a PR is not permission to ship it.

    Merge and staging deploy each wait for a named person

The team

Thirteen roles with real revision cycles

Both graphs loop rather than running straight through. In discovery a critic can send a document back to its author; in delivery a failing test or a blocking security finding sends the work back to coding with the finding in context. Cycles are bounded — after the limit the draft advances with its critique attached, because a human gate follows regardless and stalling is worse than escalating.

Discovery

Each critic returns a verdict, and a failing one routes the draft back with the changes it needs.

  • Company

    Loads organisation knowledge and frames the engagement so every later agent shares the same business context.

  • Meeting

    Turns a discovery conversation into structured notes — capture first, clarifying questions capped.

  • Business analyst

    Drafts the BRD: stakeholders, scope, requirements and acceptance language a client can argue with.

  • Product critic

    Reviews that draft for gaps and contradictions and sends concrete revisions back into the loop.

  • Architecture

    Produces the system design and then the TRD — components, data flows, interfaces, constraints.

  • Lead critic

    Critiques the architecture before you are asked to approve it, so a weak design does not reach the gate quietly.

Delivery

QA and security are conditional edges — a failure sends the work back to coding rather than onward.

  • Database

    Designs the data model and migrations that match the approved TRD.

  • UI / UX

    Specifies screens, flows and interaction states for the frontend to build.

  • Backend

    Implements APIs and services in the sandbox, verifying its own work as it goes.

  • Frontend

    Builds the interface against the UX spec and the real backend contracts.

  • QA

    Runs the tests. A failing verdict routes work back to coding with the failure attached.

  • Security

    Reviews for blocking findings and stops the run when something must be fixed first.

  • DevOps

    Prepares CI, deploy wiring and the staging path that still waits on a person.

Where the agents run

A boundary, not a convention

Every project gets its own workspace. A file path that resolves outside it is refused rather than sanitised, and only nine executables can start at all — there is no shell to inject into and no network tools, so the agent works from the approved requirements rather than from whatever it finds online.

That workspace is mounted into a container with a read-only root filesystem, all capabilities dropped, a non-root user, and memory and CPU ceilings. The same container runs the verification commands and reports their exit codes, so a passing result means the tests ran there and passed.

What stops the system flattering itself about all this →

NextThe Delivery Record — and why it can be trusted