Engineer

After Perceive, you have a fixed scope and a fixed price for the first production release. Engineer is the execution phase: roughly weeks three through ten of the engagement, though the exact calendar depends on what discovery scoped. We work in one-week sprints. Every sprint ends with a demo of working software, not screenshots. Your product owner and our engagement lead share a single backlog. Scope changes go through a formal change process; we do not silently expand.

What we build first

The first increments depend on the discovery pack. Often the sequence is: evaluation harness and observability scaffolding, then data ingestion or retrieval for the target use case, then the core agent or assistant behaviour, then integration with systems of record, then user experience and guardrails. Security review runs in parallel, not as a gate at the end. If foundations were scoped separately — lakehouse work, API layers over legacy — that may run on a parallel track with clear interface contracts.

We treat agents like any other production service. That means version control, code review, automated tests where behaviour can be specified, infrastructure as code, and environments that mirror production constraints including residency and network boundaries. Model prompts and tool definitions are versioned. Evaluation datasets are checked in. When a model upgrade breaks a regression, we know before users do.

Architecture decisions

Models and retrieval

We select models based on task requirements, latency, cost, residency and your policies — frontier APIs, open-weight models on your infrastructure, or a mix. Retrieval is designed against your actual content: chunking strategy, metadata filters, access control at query time. We do not bolt on a generic RAG demo. Tool use is defined against real APIs or approved automation paths, with timeouts, idempotency and human-in-the-loop steps where the process demands it.

Orchestration and guardrails

Multi-step agent flows are explicit state machines or graph orchestrations, not opaque loops. Each step logs inputs, outputs and tool calls. Guardrails cover input validation, output filtering, PII handling, and escalation to humans when confidence is low or policy triggers fire. Red-teaming against misuse cases from discovery is part of the build, not an optional extra.

Integration

Agents that cannot read or write the systems your staff already use will be ignored. We integrate with ERP, CRM, ticketing, document stores, internal APIs — whatever the use case requires. Where legacy systems lack APIs, we scope adapter work honestly in Perceive; we do not pretend screen scraping is a long-term strategy without saying so.

How we work with your team

You retain ownership of product direction. We retain responsibility for delivery craft. Typical collaboration: daily async standups in a shared channel, weekly sprint planning and demo, fortnightly steering with your sponsor. We embed where it helps — pairing with your engineers on integration code, aligning with your security team on review findings. We do not disappear into a black box.

• Weekly demos of working increments.
• Shared backlog with clear acceptance criteria.
• Documented architecture decision records for major choices.
• Evaluation results published each sprint against agreed metrics.
• No surprise dependencies introduced without sponsor approval.

Quality and evaluation

Every engagement includes an evaluation harness appropriate to the use case: golden sets for Q&A, scenario tests for agents, regression suites for structured extraction, human review queues where ground truth is subjective. We measure before launch and keep measuring after. Engineering without evaluation is guessing; we do not guess in production.

Performance, cost and reliability are engineered, not hoped for. Caching, batching, model routing to smaller models for simple steps, and fallbacks when upstream services fail — these are design choices made during Engineer, documented in runbooks, and tested under load where the use case requires it.

Handoff to Deliver

By the end of Engineer, the increment scoped for the first production release is feature-complete in a pre-production environment. Deliver takes it across the line: hardening, monitoring dashboards, training materials, production cutover, and the runbook your operations team or our Run team will use. Nothing about Engineer optimises for a demo that will be thrown away.

Environments and release discipline

Engineer maintains at least three environments: development for daily integration, staging that mirrors production topology and data shape, and pre-production for final acceptance. Promotion between environments requires passing automated tests and evaluation thresholds — not a manual override from a demo that worked once. Configuration for models, prompts and retrieval indexes travels as code; drift between environments is treated as a defect.

Technical debt is named, not hidden. If discovery scoped a shortcut — manual file drop before API exists, single-region before multi-region — it appears on a visible remediation list with owner and target increment. Sponsors see it in steering; it does not surface as an surprise at cutover.