Andrew Ryan: I Built an Enterprise AI Platform for $1.64 Per Run. The Hard Part Had Nothing to Do With Code

05.11.26

/

Andrew Ryan

05.11.26

Andrew Ryan is a technology executive with over 20 years of experience across software engineering, product management, and enterprise leadership. He is currently the CIO of a private alternative asset management firm, Harbert Management Corporation, where he leads AI transformation, cybersecurity, and enterprise data strategy.

Share

Part 2 of a four-part series on AI, experience, and what actually matters now. If you missed Part 1, start here.


In my last article I made a simple argument: the most valuable people in the AI era are not the ones who know the most about models. They are the ones who know the most about the work itself.

This article, I want to show you the receipts.

I also need to say something up front.

The AI wrote a lot of code. I made the decisions. Those are not the same thing.

That distinction is the whole article.

Because the scarce resource is no longer code alone. The scarce resource is judgment. Knowing what to build. Knowing what not to build. Knowing where the risk hides. Knowing which shortcuts are harmless and which ones will quietly blow up later.

That is where experience still matters. In my view, it matters more now than it ever has.

Consensus: The Analysis Engine

The centerpiece of what I built is a platform I call Consensus.

At the core, Consensus is an AI analysis engine designed to support investment committee work. It takes a large investment memo, sometimes 150 pages or more, runs it through multiple AI providers in parallel, and produces a structured analysis that includes expert personas, cross-examination, risk review, competitive intelligence, and historical benchmarking.

A full cycle costs about $1.64 in API fees.

That number gets attention, and it should. But the real story is not the cost. It is the design.

Consensus is built to evaluate the substance of the work, rather than the source. It anonymizes the analysis before the cross-examination stage, so Reviewer B does not know which model produced Analyst A’s findings.

I did not build that because it sounded clever.

I built it because I have seen the same pattern over and over in product reviews, strategy sessions, and leadership discussions. Once the first strong answer hits the table, the rest of the conversation begins to bend around it before real testing can even begin.

Good leaders understand this. Sometimes they delay speaking up in meetings, because they want to hear what the room really thinks before their own view carries too much weight.

I wanted the system to work the same way. Let the arguments stand on their own before the process gives extra credit to the source.

That is not a prompt trick. That is judgment.

The overall design principle behind the platform is simple:

AI prepares the work. People make the decisions.

That is not a slogan. It is an operating rule.

And yes, “enterprise-grade” means something specific here. The platform includes Microsoft SSO with MFA only. Deep RBAC, down to field-level permissions. Full auditability of every LLM call. CI/CD, rollback capability, and over 1,200 automated tests including end-to-end browser tests across every critical workflow. Governance, ownership, and risk tracking following the COSO published framework, all built into the platform itself. Not just intelligent output. Enterprise control.

Why This Architecture Matters

Every allocator, LP, and investment professional should be asking a harder question than “Are you using AI?”

The better question is: “How do you know your AI process is not lying to you, confidently generating falsehoods, and presenting them as facts?”

Consensus is designed to answer that.

Not by trusting one model more. By forcing the output through multiple rounds of independent analysis, blind review, cross-examination, and validation before anything gets treated as useful.

That matters.

Any firm can paste an investment memo into a public model and get something that sounds polished. That is not the same thing as a trustworthy process. The real challenge is building an architecture that reduces hallucination risk, limits bias, surfaces disagreement, and wraps the whole process in the controls, auditability, and accountability required for real enterprise use.

The platform can also run self-validation against historical deals where the outcome is already known, compare its conclusions to what actually happened, and show where the process was directionally right, where it missed, and where confidence needs to be recalibrated.

That is the point.

If your AI workflow cannot be challenged, tested, and measured against the real world, you do not have a real process. You have a summary engine wearing a suit.

And this question is not just for traditional institutional investors. Anyone allocating meaningful capital into alternatives, whether you manage a pension fund or a family office that did not exist five years ago, should be asking how the firms you trust are actually using these tools. The gap between firms that have built real AI infrastructure and firms that are just talking about it is about to become very visible.

The tool helps smart professionals move faster and prepare better. It does not remove the need for judgment. It raises the leverage of judgment.

DocIQ and the Rest of the Pattern

The same pattern shows up in the rest of the platform.

DocIQ is an AI-powered contract review and redlining tool for our legal team. Under the hood, it uses a three-stage retrieval process: find the relevant content, rerank it for precision, then reason over the best matches.

That middle step matters more than most people realize. A naive retrieval workflow can look fine in a demo and still fail where it matters most, returning something relevant enough to feel impressive while quietly missing the clause that actually matters. In production, “mostly right” is a dangerous phrase.

That same discipline carried across the platform, not just in the AI workflows themselves, but in access control, auditability, testing, rollback, and governance.

A lot of the highest-value AI work is not about showing off. It is about removing friction from processes that waste time, create risk, or keep good people stuck doing work a system should be helping with.

Where This Really Started

The truth is my path back into hands-on building did not start in a boardroom.

It started in my local church pew.

A while back, I began recording sermons on my iPhone during Sunday services, Wednesday nights, and Saturday morning prayer. I would transcribe the sermon, copy the transcript into ChatGPT, and run it through a prompt I had built for myself.

At first, my prompt was simple: build me a seven-day devotional with memory verses for the week and quotes from leaders I respect and give me daily habits that help put the message into practice.

Then the prompt got better.

Week after week, I refined it. By the end, I had a PDF with the sermon title, date, speaker, church branding, and a full devotional study guide that people around me genuinely wanted.

Friends at church started asking how I was doing it.

That is when I realized this was bigger than a personal workflow.

What started as a prompt eventually became a real software platform called Weavvr, built to help churches and ministries turn sermons into devotional guides, small-group materials, Sunday School curriculum, and social media content. But the part that surprised me was what came next: Weavvr models giving potential and demographic data across more than 30,000 U.S. zip codes, so churches can see exactly where to put that content and how to spend their outreach dollars to reach the people most likely to show up.

It grew into a real platform, with production integrations, authentication, and payment processing.

That part matters, but not because I am trying to show off a feature list.

It matters because it reminded me that the ability to build never went away. It just had not been the primary way I was creating value for a long time.

For years, my work centered on leadership, architecture, product thinking, and executive responsibility. AI did not suddenly make me technical. It gave me a faster path from judgment to execution.

And that matters, because the reason I was ready to build what I later built at Harbert is that I had already started building again somewhere else, in pursuit of something I cared about deeply and for people I wanted to serve well.

That project pulled me back in.

It reminded me what was possible.

And it reinforced the same lesson I kept seeing everywhere else: once the barrier to execution drops, experience becomes even more valuable, not less.

The Point

If you skipped straight here, here is the whole lesson.

The hard part was never just writing code.

AI can write code.

The hard part is making the thousands of small decisions that determine whether the output becomes a real product or just another fragile demo that falls apart under pressure.

How to build something people will actually use. How to design for trust. How to keep humans in the loop where the stakes require it. How to recognize the invisible step that will decide whether the thing survives contact with reality.

Those decisions do not come from training data. They come from real experience.

The AI wrote a lot of code. I made the decisions. Those are not the same thing.

And that last twenty percent, the judgment calls that no model can make on its own, is what everybody keeps underestimating.

In part 3 I want to shift from the boardroom to the dinner table. I’m going to talk about what I tell my kids, what I tell CEOs, and what I think we should actually be teaching the next generation now that the tools have changed.