Two issues ago, no-code platforms. Last issue, vibe coding and agentic AI. We said a case study was coming. This is it.
We have a habit in this newsletter of making arguments without showing the working. That is by design - the argument has to stand on its own before the evidence matters. But at some point, the architecture needs to come out of the abstract and land on the page.
This issue is that point.
Last week we described an agentic reporting system we built for a portfolio management client. A system that runs a complete reporting cycle across 20 data sources, produces formatted outputs for different stakeholder audiences, and flags exceptions for human review - end to end, without a staff member touching it.
This issue is the full breakdown. The problem, the architecture, the decisions we made and why, and the number that made it worth building.
01 - The Problem as It Actually Existed
The client manages a portfolio of 23 active investments across three sectors. Every month, they produce reports for four distinct audiences: their internal investment committee, their LPs, their board, and a subset of their portfolio companies that receive aggregated benchmark data.
Each report draws from the same underlying data but presents it differently. Different metrics foregrounded. Different narrative framing. Different formatting. Different levels of detail.
Before we built anything, we mapped what was actually happening. A senior analyst spent three days per month on this cycle. The process involved logging into six separate data platforms, exporting to spreadsheets, reconciling figures that did not always match across sources, writing narrative commentary, formatting four separate documents, and chasing down data that arrived late from portfolio companies.
Three days. Every month. From someone paid to do analytical work, not data administration.
The problem was not that the work was hard. The problem was that none of it required judgment. Every step was mechanical. The system just did not exist to do it automatically.
23 Active portfolio companies
4 Report formats per cycle
3 Days of senior staff time monthly
None of the work required judgment. Every step was mechanical. The system just did not exist to do it automatically.
02 - The Architecture, Layer by Layer
We built the system in three layers. Each layer has a single responsibility. None of them overlap. This is the design decision that matters most - when something breaks, you know exactly where to look.
System Architecture - Agentic Reporting Pipeline
01
Ingestion Layer
Pulls data from six sources on a scheduled trigger - three API integrations, two CSV pipelines with automated processing, one manual upload interface for late portfolio data. Normalizes everything to a single internal schema before anything else touches it. No downstream layer ever talks to a raw source.
02
Intelligence Layer
Runs three processes against the normalized data. Reconciliation - flags figures that conflict across sources and routes them to a human review queue before the report cycle continues. Anomaly detection - compares current period data against trailing averages and flags outliers above a defined threshold. Narrative generation - produces templated commentary for each report audience using the reconciled data as grounding. The AI does not write freehand. It fills a structured template with verified figures.
03
Output Layer
Assembles four formatted documents from the same data core. Each template is version-controlled. Changes to a template do not require touching the intelligence layer. Reports are staged for human review before distribution - a single approval step, not an editing step. The analyst reads, not rebuilds.
The key constraint we designed around: the human stays in the loop, but only at the moments that actually require judgment. Reconciliation exceptions. Approval before distribution. Everything else runs without them.
03 - The Decisions That Actually Mattered
Architecture documents make the right choices look obvious in retrospect. They were not. Here are the four decisions that shaped how this system works and why we made them the way we did.
The Decision Why It Mattered
Single internal schema before any processing
Every previous attempt at automation at this company had failed because each tool talked to raw sources directly. When a source changed its format, everything downstream broke. Normalizing to a schema first meant changes in source data only required updating the ingestion layer.
Reconciliation before generation, not after
The temptation was to generate reports and flag issues for a second-pass review. We pushed reconciliation upstream. A report built on unreconciled data that gets corrected later means the narrative commentary is wrong. Fixing figures after narrative is written doubles the review burden.
Structured template narrative, not freehand AI writing
Freehand AI commentary on financial data introduces hallucination risk. The narrative layer fills templates with verified figures. The AI is making language decisions, not data decisions. The analyst reviewing the output is checking framing, not rechecking the numbers.
Version-controlled templates as a separate layer
Clients change report formats. Investor requirements evolve. Separating templates from the intelligence layer meant a format change did not require rebuilding the system - it required updating a template file. This has already been used twice in the eight months since deployment.
The right architecture question is never what is the best tool. It is what does this decision cost us in two years if it is wrong.
04 - What It Actually Delivered
The system has been running for eight months. Here is what changed.
The monthly reporting cycle dropped from three days of senior analyst time to four hours. Not four hours of the same work done faster - four hours of review, approval, and exception handling. The mechanical work is gone.
Report accuracy improved. The reconciliation layer catches data conflicts that previously made it through to final documents. In the first month of operation it flagged three figures that would have gone out wrong.
The analyst who ran the manual cycle now uses that recovered time on work that requires her judgment - portfolio analysis, investment memo preparation, LP relationship management. The capacity was not eliminated. It was redirected.
36h Senior staff time recovered monthly
0 Reporting errors in 8 months post-launch
8mo Until ROI exceeded build cost
The build cost recovered in eight months. From month nine onwards, the system is pure return - in time, in accuracy, and in what the analyst is able to do with the capacity she has back.
That is the case for agentic infrastructure. Not the concept of it. The numbers of it.
05 - What This Means for Your Operation
Every company we talk to has a version of this problem. The details change. The pattern does not.
There is a process somewhere in your operation that a senior person runs every week or every month. It is mechanical. It requires collecting data from multiple places, reconciling it, formatting it, and distributing it. It does not require their judgment. It requires their time.
That process is the starting point. Not because it is the most exciting place to apply AI, but because it is the most legible. The inputs are defined. The outputs are defined. The gap between them is pure process. That is exactly what agentic systems are built for.
The companies that move first on this are not the ones with the largest AI budgets. They are the ones that map the process clearly before they build anything, make architecture decisions that serve the business not the technology, and design the human role deliberately - in the loop where judgment is required, out of the loop where it is not.
That is the whole arc of this newsletter in one paragraph. Own the infrastructure. Design before you build. Put the human where the human belongs.
Next issue: AfroInnovate. We have been building something specific for the African energy sector. We are ready to talk about it. Issue 004, Tuesday.
If this process exists in your company, let us map it.