AI systems our team built and runs

The problem

Sales context was spread across a third-party CRM, email, chats, and call recordings, so the full history of a deal was hard to see in one place.

What people decide

Every action the assistant proposes waits for a person to apply or reject it.

What the AI does

• Writes short deal summaries and morning and evening digests for the team chat.
• Drafts replies and follow-ups inside the deal card.
• Runs background research on a lead and attaches the findings to the deal.
• Proposes actions, such as a task or a field change, that wait for a person to apply or reject them.

How it's built

• A web app with an API, a mail poller, a call transcriber, and its own MCP server, so agents work with CRM data through typed tools.
• The assistant calls an LLM through an internal gateway and has 13 tools, such as deal brief, find records, create task, and request research.
• It runs on a schedule, on deal events, through automation rules, and when someone mentions it in the team chat.

How we check it

• A fact-anchor validator lets the assistant praise only what appears in the deal context.
• A tone gate with thresholds calibrated on 378 real messages from the team.
• Automated checks run in CI before every production deploy.

The problem

Comparing a month with the same month in past years gave numbers that didn't match. Pipelines changed, systems were replaced, and web analytics sampled the data.

What people decide

People define each metric as a contract with SQL and an oracle check, and they confirm every new dashboard.

Known limit

Explaining why a number changed is the weak part, because only a small share of deals has a written reason.

What the AI does

• Answers questions in plain language inside the BI tool.
• Takes every number from a versioned metric contract through a parameterized query, not from free-form SQL.
• Finds supporting quotes in sales conversations and call transcripts, and searches the internal wiki.
• Drafts a dashboard from existing charts, which a person creates with one click.

How it's built

• PostgreSQL with pgvector. Raw data lands unchanged, and units are normalized only in the marts layer.
• 15 ingestion pipelines from 9 source types: CRM, search console, SEO platform, rank tracking, web analytics, ad accounts, accounting, task tracking, and the wiki.
• Apache Superset for dashboards, with the chat embedded as a widget, and multilingual embeddings over masked text for search.

How we check it

• The chat runs under a read-only database role with a 30-second statement timeout and no access to raw personal data.
• Code, not the model, verifies each answer: every number carries the contract, version, and result hash it came from.
• A sentinel checks that personal data masking ran before text reaches the search index.

The problem

A specialist wrote every brief for copywriters by hand and repeated the same research steps for each page.

What people decide

A specialist accepts each brief, returns it for edits, or rejects it with one button in the team chat.

What the AI does

• Every 30 minutes, a discovery step looks for gaps against competitors and for pages ranking 11 to 30.
• Machine gates check demand, intent, duplicates, and overlap with existing pages before a brief is written.
• An agent writes the brief, and three gates check that it queried the SEO tools, that its structure is complete, and that it matches the live site.
• Drafts go through four critics in parallel: fact check, AI-tell lint, voice, and format.

How it's built

• 24 specialized agents for research, briefs, drafting, critique, publishing, and analytics.
• The brief loop runs on a schedule on our own server and posts each brief with its review buttons.

How we check it

• Gates are tested on real defects: a gate has to fail on a broken brief and pass on the fixed one before it goes live.
• Cheap checks run first, so a person only sees briefs that passed every gate.

The problem

An editor's comments on AI drafts fixed one article at a time, and the same mistakes came back in the next draft.

What people decide

The editor reviews on a page that renders like production and approves publishing. A script then publishes and checks the live page.

What the AI does

• Writes an article or an update from an accepted brief and saves it as a draft.
• Answers each comment with a status: fixed, declined with a reason, or superseded by the editor's own change.
• Edits only the commented part, and untouched blocks stay byte-for-byte the same.
• After publishing, a retro turns repeated comments into rules for the next drafts.

How it's built

• Rules climb a ladder: a prompt rule, then a critic checklist item, then a deterministic lint.
• The model writes text, and code makes every state change. Nothing leaves the loop without an explicit apply step.

How we check it

• A rule becomes a lint only after it catches a real commented fragment in a red-green test and fires on at most 5% of the last 20 published articles.
• 659 automated tests cover the loop's tools.

The problem

Finding a product worth building meant reading hundreds of store listings and checking search demand for each one by hand.

What people decide

A product owner sets the niches and thresholds and picks the candidate. The loop only proposes.

What the AI does

• Reads new listings in chosen niches and describes each product: the one job it does, who uses it, and how it earns.
• A second, independent pass re-checks the one-job verdict. Disagreements are marked as disputed, not dropped.
• Classifies which search results are software, so demand numbers count real competitors.

How it's built

• Code collects listings, removes duplicates against the team's idea base, and filters by user count.
• Code, not the model, measures search volume, difficulty, the top 10 results, and whether a name is taken. Measured facts overwrite the model's claims.
• Deterministic scoring out of 50 and a demand gate of 1,000 searches a month.

How we check it

• The model has no web access, no shell, and no credentials.
• A canary query that must return results, budget caps, a stop file, and a dead-man check on another host.
• Counts per bucket must add up to the input, so no candidate disappears silently.

The problem

Hiring data was spread across job boards, résumé files, and interview notes.

What people decide

A recruiter imports candidates, moves them between stages, and records the reason for every rejection.

What the AI does

• Scores each résumé against the role and explains the score.
• Analyzes interviews from the meeting transcript.
• Searches a job board: extracts requirements from the role, ranks results in a fast pass and a deep pass, and shows the top for review.
• Exports an AI report to PDF or Word.

How it's built

• A TypeScript API with schema validation, PostgreSQL, S3-compatible storage for résumés, and a React app.
• A browser extension for one-click import, calendar and video integration for interviews, and signed webhooks for recordings.
• Role-based access and an audit log. LLM calls use structured outputs with a strict JSON schema.

How we check it

• Every AI result comes back in a fixed JSON schema at a low temperature, and a failed call is retried once.