Operational intelligence is sociotechnical

A scan of the Slack channels for a recent private equity deployment of Clonal (our operational...

A scan of the Slack channels for a recent private equity deployment of Clonal (our operational intelligence platform) might confuse you at first. There is far less talk of dbt models, evals, or Monte Carlo simulations than you would expect, and far more about “human factors,” “emotional resonance,” and endless conversations about how to facilitate alignment. The human kind, not the AI model kind.

Creating software is increasingly the easy part of our job. The harder part is building systems that people trust, use, and improve as they work with them. In financial services that matters a great deal. On the day we deploy Clonal, it is inert. Even once data is flowing, connecting sources and generating summaries does not create value on its own. Value shows up when better context changes front-line work: how analysts prepare, how ICs decide, how BD coordinates, and how the firm acts on an investment.

Our PE work shows this. Neither our clients nor we want another place to go look things up. We want the firm’s own history available to the person making a call, when they are making it. Part of that is an engineering problem. The rest is social. It takes careful system design and iteration, and it takes what we call human motions: the recurring things people do around the system, like walkthroughs, reviews, and deciding who owns what.

Workflow even over feature

Consider how a deal lead prepares for a banker conversation meant to generate dealflow. Their questions are simple: What have we discussed before? Which companies are coming to market? What did we pass on, and why? What should we ask next?

A technically impressive platform can make that preparation harder if the answers are scattered across overlapping screens, abstract scores, and unfamiliar categories.

Early on, we built these as fully realized features, with visuals and styling. John Cutler, our product lead, noticed that this collapsed several mental models into one. The client was reacting to the data, the logic behind it, and the presentation all at once, so we could not tell which of those their feedback was about, and we rarely got a clear read on the actual state of the graph data. Now we start by understanding the question and writing sample queries, then sit with the client and walk through what the data surfaces. It’s a bit like paper-prototyping the insight.

The operating model lives inside the architecture

In ontology design (we call it “topology”), small distinctions carry large consequences.

A company is not a deal. One company can have multiple transaction processes over time. An internal decision to pass may not be the same as communicating that decision externally. A fund passing does not mean the company is no longer in market. A missing interaction record does not prove a relationship has gone cold. We hit these constantly. They are the everyday semantics of the business.

If the platform collapses those distinctions, it can present a clean interface that misrepresents reality. Forward-deployed engineers and product managers work through system design with the client so the distinctions show up in the data model, workflow ownership, permissions, and visible action states. Without that regular contact, we build things that function but don’t work.

Closing workflow loops and learning loops

Forward-deployed work keeps paying off after implementation.

Engineers and product leaders working alongside users see the gap between a requested capability and a usable routine. They watch someone navigate a real deal, investigate an unexpected comparable, or struggle to find the next action. That proximity exposes problems a requirements document rarely captures. Cheap code lets us compress those cycles a lot, but design and interaction with real people doing real work is the most important kind of HITL we do.

We are borrowing heavily from DDD and service design to make these sessions useful: short walkthroughs, focused wargaming, testing against real records, visible feedback tracking. All of it helps clarify what “good” means. Sometimes we can gather that from the environment. When we step into judgment-heavy work like deal evaluation, we have to find ways to turn intuition into evaluation.

Trust is designed through restraint

In investment work, an attractive black-box score is usually less useful than a dated note with a clear source. A label like “cooling relationship” sounds intelligent, but it backfires when the professional knows they have had several recent conversations. “No recorded interaction since this date” claims less, and the reader can act on it.

The same applies to automation. An elapsed deadline can prompt a review, but it should not declare a process dead on its own. A queued update should not appear completed. Unknown data should stay unknown instead of becoming a confident-looking zero. None of this is hard to express in software, even hand-written code. It is easy to overlook in design.

The deliverable is a repeatable capability

Our goal is for clients not to need our deployment teams. We aim to leave behind an organization with clearer ownership, reusable context, reliable decision pathways, and the ability to keep improving its own system.

The software we build and configure provides the machinery, and the human motions around it make it operational.