I've been staring at a lot of complex systems recently. Supply chains that run from initial sales conversations through to delivering physical data centres and servicing customers long-term. Joiner-mover-leaver flows that touch every corner of an organisation - who can join, what happens when they do, what about edge cases X, Y, and Z.

The natural reaction to this kind of complexity is paralysis. With so many things and interdependencies, it becomes very difficult to understand how to even go about it. Most people either pick something at random or try to fix everything at once. Neither works particularly well.

Why The Goal Changed Everything

A couple of years ago I read The Goal by Eliyahu Goldratt. It's technically a book about manufacturing, but it reads like a thriller. The story follows a plant manager trying to save his factory from being shut down, and Goldratt weaves the theory through the narrative in a way that makes complex ideas click.

There's a scene early on where the main character takes his son's scout troop on a hike. The kids are walking in a line, but the line keeps stretching out - some kids walk faster, some slower, and gaps form. He realises that the speed of the whole group is determined by the slowest kid, and that trying to speed up the fast kids does nothing. The constraint is the bottleneck.

Then Goldratt applies this exact thinking to difficult manufacturing problems, and suddenly you see it everywhere.

The core framework is the Theory of Constraints, built around five focusing steps: identify the constraint, exploit it (get everything you can from it), subordinate everything else to it, elevate it (invest to remove it), and repeat. Finding constraints is easy enough - it's how you fix them that's interesting.

Here's a practical example. I did some work for a startup where I looked at their dev team's load. They were clearly not delivering as they should be. Working many late nights, constant stress, missed deadlines. The typical response would be to hire more developers or push harder.

Instead, I looked at how information flowed through the org from sale to delivery - like water through pipes. Where was it pooling? Where was it getting stuck? I focused on the top ONE thing to fix. Then another. Then another.

Only three changes, properly implemented, got them delivering faster with ZERO late nights and everyone in the org happy. Not ten initiatives. Not a transformation programme. Three targeted interventions at actual constraints.

This is what most people miss. They see a complex system and try to optimise everything. But optimising non-constraints is waste. You can make a fast part of the system faster and achieve nothing, because the bottleneck is elsewhere.

Why I Built Sonde

The problem is that applying this thinking systematically requires discipline. It requires asking the right questions, honestly assessing current state versus desired state, and not jumping to solutions before you've actually understood the problem.

Most of us are terrible at this. We mistake symptoms for causes, propose fixes before diagnosis, and lose track of what we've established as conversations meander in circles.

I wanted something that would enforce the discipline. Something that would ask the right questions, track what's been learned, and refuse to let me skip ahead until the foundations were solid.

So I built Sonde.

What Sonde Actually Does

Sonde is an AI-powered problem-solving tool that guides you through a structured seven-phase diagnostic framework. The name comes from the scientific instrument - a probe sent to gather data from hard-to-reach places. That's exactly what this does: it probes into organisational complexity to surface root causes, constraints, and leverage points.

The seven phases map directly to how you'd apply constraint-based thinking to any complex problem:

Problem Definition - Identify the actual problem, not the presenting symptoms. The AI asks probing questions until you hit something structural. You can't move forward until you've articulated a root cause rather than just a complaint. This stops you from optimising the wrong thing.

Current State Analysis - Map the system as it actually operates, not as the org chart says it should. Like tracing how water flows through pipes. This phase is about brutal honesty.

Target State Definition - Define what "fixed" looks like in concrete, measurable terms. Not "better culture" but "deployment frequency increases from weekly to daily." Without this, you can't know if you've succeeded.

Constraints and Leverage Points - This is where the Theory of Constraints meets Donella Meadows' work on leverage points. Find the bottleneck. Find where small changes create large effects. This is the critical phase.

Intervention Design - Design sequenced actions that address constraints in the correct order. Just like my startup example - not ten things, but the right three things in the right order. Dependencies matter.

Execution - Implement with feedback loops, expecting the plan to need adjustment.

Institutionalise - Ensure changes persist after the initial push. If you leave and it reverts within six months, you didn't actually fix anything.

The AI guides conversations through each phase, extracts knowledge automatically (facts, constraints, decisions, stakeholders, risks), tracks information gaps, and generates visual diagrams of the system as understanding evolves.

Testing It on a Real Project

I've been testing Sonde on my prenatal genetics project - the AI-enhanced NIPT testing work I'm doing with Emergent Ventures. It's a good test case because the problem space is genuinely complex, spanning synthetic data generation, machine learning model development, clinical validation, and regulatory considerations.

What surprised me was how effectively the AI surfaced gaps I hadn't consciously articulated. It kept pushing on the current state versus target state distinction, pointing out places where my understanding was fuzzy. It suggested sequencing I hadn't considered - "if you want to do X, don't forget you'll need Y in place first." It caught assumptions I was making without realising.

I haven't run through the complete lifecycle yet, but even partial use has been valuable. The structured approach forces a rigour that's easy to skip when you're just thinking through problems in your head.

The Technical Stack

Nothing fancy here. Go backend with SQLite for persistence, Vue 3 frontend, Claude for the AI conversations, and Cytoscape.js for diagram rendering. Everything runs in Docker.

The key technical challenge is knowledge extraction - parsing Claude's responses to identify and categorise facts, constraints, leverage points, decisions, and gaps. This builds up a structured knowledge base that persists across sessions. You can return to a diagnostic project weeks later with full context preserved.

I wrote about building AI integrations in Go previously, and a lot of that experience fed into how Sonde handles the Claude API.

Who This Is For

Sonde is for anyone who takes organisational problem-solving seriously. Founders trying to untangle their operations. Engineering leads trying to understand why their deployment pipeline takes two weeks. Operations people mapping out processes that have grown organically over years.

The goal isn't to replace thinking - it's to augment it. The AI is a thinking partner that asks better questions, challenges assumptions, and ensures you're being rigorous. It's modelled on how a good consultant operates: probing, synthesising, pushing for specificity.

I've found that AI works best when it provides scaffolding rather than answers. Sonde doesn't tell you what your constraint is - it helps you figure it out for yourself. That's a meaningful difference.

If you're interested, you can try it at sonde.ksred.com. I'm still iterating on the prompts and phase gate criteria, but the core diagnostic framework is solid and it's already proving useful for working through genuinely complex problems.