We field agent crews.

A single agent doing five jobs is five prompts braided together, and when it fails, you don't know which of the five failed. A crew separates the jobs: one narrow agent per task, one lead to route, one curator to tend memory and one human to approve. Each piece has its own eval, budget and failure mode.

Generalist agents demo well and ship badly. Once one is in production with real telemetry, the failures interleave: bad retrieval poisons drafting, bad drafting fools the checker, and the trace becomes unreadable. Crews stay debuggable because each agent has one job and one eval. We do use the big models, but we don't ask any single instance to do five things at once.

Most "agent memory" is one context window stuffed until it overflows. We separate memory by lifetime: tier-01 (charter, pinned), tier-02 (long-term project facts, curator-written), tier-03 (per-task scratchpad, disposable) and tier-04 (shared knowledge base, read by every agent in the crew). Each tier has its own retention rule, write policy and size budget. Nothing crosses a boundary without the curator's approval.

Memory rots if nobody tends it. The curator is a dedicated agent whose only job is to score what gets written, promote what proves useful, demote what goes stale and prune the rest. Without one, long-term memory fills with contradictory facts. With one, it stays small, recent and relevant, which is when it's worth its tokens.

Tokens and latency both cost money. A 60-token prose handoff and a 22-token typed handoff can carry the same payload, but one parses on the wire and the other has to be re-read. We keep reasoning steps in natural language, and put telemetry, status and routing on a typed channel. A crew that runs all day pays for every word it doesn't need to say.

The human is the final gate, who approves, edits or rejects, and doesn't step in on every turn. Agents do the research, drafting, checking and routing on their own. The human sees a packaged outcome with citations and a diff, then signs off or sends it back. For the Article Crew that's an editor on every piece. For the BD Crew it's a person approving every send. For WaterDoctor it's senior wGrow engineers on the ground.

That's our comfort zone. We work with audited workflows, regulated data and long-running loops, designed with PDPA, MAS and IMDA in mind from the first whiteboard session. Every crew run is logged, every memory write is attributable and every human approval is recorded. The crew runs on the audit trail from the start.

Crews are model-agnostic by default. We build on Anthropic Claude, OpenAI and Gemini, and choose per agent based on what each role needs: long-context reasoning, structured output or cost. Memory lives in Postgres and a vector store we control, outside the model provider. If a provider changes pricing, deprecates a model or goes down, we swap. No single vendor owns your crew.

Most engagements start in 2–3 weeks. We open with a one-week diagnostic that ends with a crew shape, an eval plan and a weekly cadence. From there the first crew is usually running against real data inside a month, behind a human gate. We don't ship single-agent demos, and we don't ship without an eval harness on commit.

Both. For most engagements we design the crew, ship it and hand over with an eval plan you can run yourself. For deeper work, like our WaterDoctor engagement, two senior wGrow engineers embed with the client team on the ground, working on sensor data, control loops and regulator-readable reports. The crew model stays the same, and the operating model changes.