Agent workflows for go-to-market and engineering operations

What we built

• Lead generation and outreach service

  A FastAPI service organised into campaign, lead sourcing, ideal-customer profiling, sequencing, outreach and reporting modules, paired with its own React console.

• Newsletter assembly crew

  A multi-agent crew with its own knowledge base, configuration, tools and HTTP entry point, plus a web app for editing and dispatch.

• Engineering agent service

  A FastAPI service shipping two distinct agents — one that drafts technical blueprints, one that reviews code — behind a shared console.

Architecture

Two different orchestration frameworks are in use across the three products, not one standardised choice. The newsletter product runs a role-based multi-agent crew; the other two compose chains directly. Reading them side by side, that is a deliberate fit-to-task decision rather than drift: a newsletter has distinct editorial roles to model, and a code review does not.

Model providers are not hardwired to a single vendor. The lead-generation service carries adapters for more than one provider in the same dependency set, which is the cheapest available insurance against a model being deprecated underneath a running product.

Outreach is multi-channel by construction. Three text channels are separate modules under one outreach package, and a voice SDK in the same service adds a fourth — so adding a channel is a new module rather than a rewrite of the sequencing logic.

Datastore choices diverge by product rather than being standardised: relational storage with an async driver for the lead pipeline, a document store with a cache alongside it for the engineering agent. Both sit behind the same managed platform for authentication and hosting, which is what keeps three small products from needing three sets of operational plumbing.

Data acquisition is delegated to a hosted scraping platform rather than maintained in-house — the same trade as the model providers, and for the same reason: neither is where the product's value sits.

Stack

Agent services

• Python
• FastAPI
• LangChain
• CrewAI

Model providers

• OpenAI
• Google Gemini

Data

• PostgreSQL via SQLAlchemy and asyncpg
• MongoDB via Motor
• Redis
• Supabase
• pandas

Channels and acquisition

• Email, Telegram and WhatsApp modules
• Vapi voice SDK
• Apify scraping platform
• BeautifulSoup
• Google Workspace APIs with OAuth

Consoles

• React
• Vite
• TypeScript

Scale

Counts that can be re-derived from the same repositories. Nothing here is a business result — a repository cannot evidence one.

• Six repositories across three products.
• 292 commits in total — 141 on the newsletter product, 115 on the engineering agent, 36 on the lead-generation product.
• Two orchestration frameworks and two model providers across the set.
• Four outreach channels in the lead-generation product: three text, one voice.

Where the evidence stops

• All three products have been dormant for months; the most recent commit across the six repositories is from December 2025.
• Each product is individually small. The case they make together is about a repeatable architecture, not about the scale of any one of them.
• The consoles started from a generated project starter rather than an original design system, so nothing here evidences interface design work.
• These are internal tools. No client commissioned them, and no business result is recorded in the repositories.

Evidence

Each statement above, and the artefact it was read from. The client cannot be named, so the sources are given instead.

• Six repositories across three products, each product a service plus a console.

  SourceRepository trees and manifests: a `pyproject.toml` or `requirements.txt` in each service, a `package.json` in each console.

• Two orchestration frameworks are in use, not one.

  Source`langchain`, `langchain-openai` and `langchain-google-genai` in the lead-generation service's requirements; `crewai` and `crewai[tools]` in the newsletter service's.

• More than one model provider is wired into the same service.

  SourceThe lead-generation service's requirements list both an OpenAI and a Google Gemini LangChain adapter.

• The newsletter product is a multi-agent crew with its own knowledge base.

  SourceSibling directories inside the newsletter service package: a knowledge-base folder, configuration, crews, an HTTP endpoint, tools and utilities.

• The engineering agent ships two distinct agents.

  SourceTwo agent packages under that service's `src/agents/` — one for blueprint drafting, one for code review.

• Outreach spans four channels.

  SourceThree channel modules under the lead-generation service's outreach package, plus `vapi_server_sdk` in the same service's requirements for voice.

• Datastore choices differ per product.

  Source`SQLAlchemy`, `asyncpg` and `psycopg2-binary` in the lead-generation service's requirements; `motor` and `redis` in the engineering agent's.

• Data acquisition is delegated to a hosted platform.

  Source`apify-client` in the lead-generation service's requirements; `beautifulsoup4` in the newsletter service's.

• The consoles began from a generated starter project.

  SourceThe lead-generation console's `package.json` carries the starter's default project name rather than a project-specific one.

• 292 commits across the six repositories, ending in December 2025.

  SourceSum of `history.totalCount` per default branch, GitHub GraphQL API: 141, 115 and 36. Latest `committedDate` across the set is 2025-12-29.

Related capability

AI Agent Development