Building a Relationship-Intelligence Engine, Solo, in Claude Code

A professional-services firm needed its leaders to always know who to reconnect with, and when, without ever touching a spreadsheet. The catch: the people who needed the intelligence had no time to maintain a system, and no interest in learning one.

I designed and built the answer solo in Claude Code: an agentic relationship-intelligence engine that turns the data the team already generates into a weekly, decision-ready digest. It runs on a schedule, enforces its own data integrity, and asks nothing of the people it serves. The build shipped with 460+ automated tests, 18 database migrations, and a 36-hook governance layer, all written by one person.

The challenge

The people who needed the intelligence were the least able to produce it.

• The team generated valuable relationship signals every day just doing their jobs, but had zero time to log, tag, or maintain anything.
• Off-the-shelf CRMs assume someone will do the data entry. No one would.
• The useful signal was scattered across public data, news, and professional-network activity, and it went stale fast.
• Any system had to be trustworthy enough that a busy person would act on its output without re-checking the work.

So the real constraint was never “build a database.” It was: build something that produces reliable, high-value output from data exhaust, with zero manual input from its users, and never quietly corrupts itself.

The approach

I ran this through my PRIME framework, from architecture to adoption.

R: Roadmap & Strategy

I designed a five-layer architecture that separates data ingestion, canonical storage, enrichment and qualification, human approval, and delivery. Each layer has one job.

The load-bearing decision was an adapter pattern for the data sources. Any single source could be swapped without rewriting anything downstream. That choice paid off later: when one planned data source did not survive contact with reality, only its adapter changed, not the engine.

I: Implementation Planning

I wrote the system as specifications before writing code: 17 canonical, version-controlled design specs covering the workflows, the database tables, the governance hooks, and the surfaces the team would actually see.

One principle ran through all of it. Skills define what the agent should do. Hooks define what it is never allowed to do. Keeping those two separate is what made the output safe to trust. The hook catalog became the contract: 36 documented data-integrity rules, each mapped to the specific invariant it protects.

M: Migration & Execution

I built it in Python on a Supabase (Postgres) backend, with Claude doing the language work: a fast Haiku-class model for classification, a Sonnet-class model for extraction.

• 18 versioned migrations stood up the canonical tables, views, and indexes.
• 27 of the 36 catalogued hooks are implemented as pure functions over a database transaction, each with a happy-path test plus one test per failure mode.
• Three orchestrated workflows handle import, discovery, and monitoring. They run weekly and idempotently on GitHub Actions cron schedules, so re-running one produces the same result.

The whole thing shipped with 460+ automated tests. Drift between the documented contract and the running code was treated as a bug, not a detail.

E: Enablement & Adoption

Output reaches the team two ways: a weekly digest email and a lightweight operator console with a roster view and an approvals tab.

The approvals tab is the single human-in-the-loop gate. The system proposes, a human confirms, and nothing consequential ships unreviewed. Adoption cost to the people it serves: zero training and zero data entry. They read an email.

The results

A production system, built solo, in weeks. 460+ tests, 18 migrations, a 36-hook governance layer, and three scheduled workflows, all from one engineer.

Zero manual input from the people it serves. Every field is derived from data the team already generates, so the system maintains itself instead of asking humans to feed it.

Trustworthy by construction. The hook layer flags or refuses bad writes at the database boundary rather than letting the engine silently corrupt itself, and the approval gate keeps a human on every consequential action.

Swappable foundations. The adapter pattern proved itself when a planned data source did not work in practice. One adapter changed. The engine did not.

Why this matters

The hard part of most internal AI systems is not the model. It is building something reliable enough that a busy person acts on its output without re-checking it, and cheap enough to run that it outlives the demo.

That takes production discipline: tests, migrations, a governance layer that refuses bad data, and a human approval gate on anything that matters. It also takes restraint. The best internal tool asks nothing of the people it serves.

If you have valuable signal trapped in the day-to-day work of people who have no time to manage a system, that is an AI workflow automation problem, and it is solvable. The engineering here spanned every phase of my PRIME framework, from architecture to adoption.

Stack and validation

Built in Python on a Supabase (Postgres) backend, with the Claude API doing the language work: a Haiku-class model for high-volume classification and a Sonnet-class model for extraction. External data arrives through MCP integrations behind a swappable adapter layer, and the three workflows run on weekly GitHub Actions cron schedules. The whole system follows a five-layer architecture, and it was designed, specified, and built end to end in Claude Code.

The governance layer is the validation story. The build shipped with 460+ automated tests, and each of the 27 implemented hooks carries a happy-path test plus one test per failure mode. The hook catalog is the contract: any drift between a documented data-integrity rule and the running code is treated as a bug, not a detail. The workflows are idempotent, so re-running one produces the same result, and a human approval gate sits in front of every consequential write. Bad data is refused or flagged at the database boundary rather than silently absorbed.

Related builds: contact-movement monitoring for a B2B tech-services firm and a knowledge assistant for a professional-services firm solve adjacent relationship and knowledge problems.

Want a system like this inside your business? Schedule a consultation or send a message.