How we work

A deliberate path from friction to a working system

This is the client journey every Astraeus engagement follows, whether you work with us for three weeks or three years.


  1. 00

    Stage 00

    Qualify

    What kind of intervention fits here?

    Before a paid engagement, we run a short qualifying conversation. Some problems need clearer ownership, better use of an existing tool or a normal automation. Some justify AI assistance or an agent workflow. We tell you which category the work belongs in before discussing a build.

  2. 01

    Stage 01

    Diagnose

    Map the terrain before building.

    Work that crosses several systems or carries meaningful risk starts here. We map the workflow, volume, exceptions, data and current tools. The output is a decision document: a ranked opportunity map and a recommended first build, with scope and rough estimate. You can commission it with us, take it elsewhere or shelve it.

  3. 02

    Stage 02

    Build

    Design and deploy the first bounded system.

    We build the smallest credible intervention against the recommended opportunity: automation, AI assistance or an agent workflow. It connects to the existing tools, includes approvals and exceptions, and leaves with documentation and training. Automated actions remain observable and reviewable.

  4. 03

    Stage 03

    Operate

    Run, evolve, expand.

    A workflow that works this month may drift next quarter as the business, tools or source data change. Managed work covers monitoring, exceptions, access review, cost control and measured changes to the deployed system.


Working principles

The rules we hold ourselves to

  • We don't automate what shouldn't exist.

    If a process is broken, an agent will just break it faster.

  • We build for the operator, not the dashboard.

    Systems are designed around the humans who will run them.

  • Documentation is a deliverable, not a chore.

    Every build leaves with a runbook your team can actually use.

  • No black boxes.

    Automated actions are observable, reviewable, and interruptible.

  • We evolve systems; we don't abandon them.

    Shipping is day one, not delivery.


What this looks like

A typical engagement, end to end

A fintech operations team contacts us. They have three people manually processing document batches every morning: extracting values, cross-referencing against a policy table, flagging exceptions. The work is repetitive, error-prone under time pressure, and growing faster than headcount. They want to "use AI to automate it."

In the qualifying call, we find that two of the three operators have never used an AI tool beyond ChatGPT occasionally. The team has no documented process for the document workflow: the logic lives in spreadsheets and the heads of the senior operator. There is no error log, so we cannot establish a baseline error rate. They are a high-risk context under the EU AI Act, which means the build will need observable state, human-in-the-loop checkpoints, and a full audit trail from day one.

We route them to Enable first, not Diagnose. Two weeks of operator training on document-processing tools, a structured process documentation exercise, and a guided pilot on a narrow slice of the workflow with a human reviewing every output. At the end of Enable, the team has working knowledge of AI tools, a documented process we can actually audit-map, a clear error baseline from the pilot, and the confidence to commission a serious next step.

Diagnose follows. Three weeks. We map the full document workflow and find that exception handling is where the team loses the most time (it accounts for forty percent of the time but only fifteen percent of volume). The decision document recommends a two-agent system: one for extraction and classification, one for exception triage with a mandatory human-approval gate before any action is taken. Scope, rough cost, and compliance constraints are all in the document.

Build takes six weeks. The orchestration layer is designed first. State schema, audit log, approval-gate logic, operator dashboard. The agents are built against it. We integrate with their existing document storage and policy table. The human-approval gate is not an afterthought; it is the second thing we build, after the state layer. Handover includes a runbook and two training sessions for the operators who will run it.

Three months later, the team is on a monthly retainer under Manage. The exception-triage agent has been extended to cover a second document type that emerged after launch. The audit trail produced its first real value when a policy table error caused a batch of misclassifications: we identified the scope, rolled back the affected cases, and documented the incident in under two hours.

This is not a case study. It is a composite of how engagements actually go when the approach is followed. The stages are not formalities. Each one produces something the next one depends on.


Start with a conversation.

Book a free consultation