Compass: Deciding Where AI Actually Fits in How You Build Software

Most teams do not have an AI problem. They have a decision problem that happens to be about AI.

The situation this is built for

A familiar version goes like this. Someone senior asks what the team is doing about AI. The answer is honest but unsatisfying: a few engineers use an assistant in their editor, someone prototyped a chatbot against internal documents, and there is a slide deck circulating about agents. Meanwhile the list of candidate tools grows every month, each with a persuasive demo and a different assumption about how you already work.

Readiness inside the team is uneven. One squad has strong test coverage and fast CI; another is maintaining a service where a change takes three days to verify. The data that would make a promising use case viable is scattered across systems with unclear ownership. Nobody is quite sure which constraints are real and which are habits.

The instinctive response is to pick tools. That is where the trouble starts, because a tool choice made in isolation quietly assumes several things are already true:

That your delivery practices can absorb the change — that code review, testing, and release processes will still hold when more code arrives faster.
That the platform underneath can support the use case — that the data is accessible, described, and trustworthy enough to be worth pointing a model at.
That the team can supervise the output — that someone can tell a good result from a plausible-looking wrong one, and has the time to check.

When those assumptions do not hold, the tool is not the thing that fails. Delivery is. The pilot stalls, the enthusiasm drains, and the organisation concludes that “AI didn’t work for us” when what actually happened is that a reasonable idea was applied to an unready context.

What Compass is

Compass is a decision-support application for AI adoption in software delivery and platform architecture. Its central idea is straightforward: assess the context first, understand the trade-offs that context creates, and turn the findings into a practical adoption plan the team can actually run.

It is not an autonomous engineering team. It does not write your services, deploy your changes, or enforce policy on your behalf. It is also not a universal AI strategy product — it is deliberately scoped to how software teams build, ship, and operate systems.

The work is organised around two complementary perspectives:

Software delivery. Which AI tools and workflows fit the way this team actually builds and ships software?
Platform architecture. Where could AI add value inside this system, and which foundations need attention before that is sensible?

Teams often start with one and discover they need the other. A delivery assessment surfaces a promising use case that turns out to depend on data the platform cannot yet serve. An architecture assessment identifies a strong opportunity that the team has no realistic capacity to supervise. Holding both perspectives is the point.

How it works

You describe the project and the team: what you are building, who is on it, how you work now, which tools you already use, and the constraints you are operating under. Where a platform perspective is relevant, you describe the capabilities that matter for it.

From there you explore delivery needs, platform needs, or both, through guided assessments. Compass uses that context to produce findings you can review rather than verdicts you have to accept: AI readiness and project complexity insights, recommendations across the software development lifecycle, architecture capability and gap analysis, candidate AI opportunities with their prerequisites, and risk, oversight and governance considerations attached to each.

You then compare possible changes. Save an assessment, adjust the assumptions, and look at an alternative scenario side by side — a more cautious rollout against a more ambitious one, or the same ambition with a different sequence. From the comparison you agree priorities and a phased plan, and produce reports you can take into a leadership conversation.

Later, when the situation has moved, you revisit the assessment.

flowchart LR
    A["Project and team context"] --> B["Guided assessment"]
    B --> C["Software delivery perspective"]
    B --> D["Platform architecture perspective"]
    C --> E["Findings and recommendations"]
    D --> E
    E --> F["Compare options and priorities"]
    F --> G["Phased adoption plan"]
    G --> H["Reassess as circumstances change"]
    H --> B

The loop at the end of that diagram is a team activity, not continuous automated monitoring. Nothing is watching your repositories and silently updating a score. Reassessment happens when you decide something has changed enough to warrant it — a platform capability landed, a team grew, a pilot taught you something. Saved assessments, history, and trends exist so that when you come back, you are comparing against what you actually thought last time rather than against memory.

Shared workspaces and comments serve the same purpose. The output of an assessment is most useful as something a group argues with.

A worked example (hypothetical)

The following scenario is illustrative. It is not a customer case study, and it does not represent specific Compass outputs.

Imagine a team of nine maintaining an established logistics application. The codebase is a decade old in places, test coverage is patchy in exactly the modules that change most, and the release cadence is fortnightly. Two engineers use an AI assistant informally; nobody else does. A board member has asked why delivery is not faster.

Working through a delivery assessment, the team articulates something they already half-knew: their bottleneck is not typing code, it is the time between “change written” and “change trusted”. That reframes the shortlist. Generating more code faster into a codebase with weak verification is not obviously an improvement. Bounded assistance in areas with clear feedback — test scaffolding, refactoring under existing coverage, review support — looks more defensible as a first step.

An architecture perspective adds a second finding. The team is interested in an AI-assisted feature for exception handling in shipment data, and the case for it is genuinely good. But the assessment surfaces prerequisites: the relevant data is spread across two systems with inconsistent identifiers, and there is no established path for a human to review and correct a suggested resolution. That does not kill the idea. It sequences it.

The team then compares a more ambitious scenario — pursuing the customer-facing feature within the quarter — against the cautious one. Seeing the prerequisites and oversight requirements laid out next to the timeline makes the trade-off concrete rather than rhetorical. They choose the cautious sequence, with the ambitious use case explicitly parked and a review checkpoint set for when the data work completes.

The valuable output here is not a tool recommendation. It is a defensible answer to “why aren’t we doing the exciting thing yet”, and a date on which that answer gets re-examined.

Who it is for

Engineering leaders deciding where adoption effort goes first across several teams with different readiness, and needing to explain that ordering to people above and below them.
Technical founders balancing genuine ambition against a small team’s capacity, who need to know which single change is worth the disruption this quarter.
Architects evaluating whether the platform can support a proposed AI capability, and what has to be true first.
Delivery managers working out how a change lands in existing workflows — what it does to review load, testing, estimation, and the shape of a sprint.
Consultants who need a repeatable way to structure a client assessment and communicate recommendations that hold up under challenge.

Why this shape of tool works

Context makes recommendations relevant. A recommendation that ignores your test coverage, your release process, and your team’s experience is a generic list. The same recommendation, produced against a described context, can be argued with on its merits.

Two perspectives expose different constraints. Delivery assessment finds workflow and capacity limits. Architecture assessment finds data, integration, and foundation limits. Teams that only look at one tend to be surprised by the other.

Explanations matter more than conclusions. Findings come with the reasoning that produced them, which is what lets a team disagree productively. A recommendation you cannot interrogate is not decision support; it is an instruction.

Comparison beats commitment. Examining two plausible futures side by side is cheaper than discovering the difference by living through one.

Governance outputs are planning aids. Risk considerations, human oversight guidance, and governance templates help a team think through supervision and accountability before adopting something. They are inputs to your own process — not evidence of compliance, and not automated enforcement.

Two design principles are worth stating plainly, because they are easy to get wrong.

The first: unknown is not the same as absent. If a team cannot answer a question about their data lineage, the honest reading is that they do not currently know — which is itself useful information, and often the first thing worth fixing. Treating every gap in knowledge as a confirmed deficiency produces a bleaker and less accurate picture than the team deserves.

The second: readiness is not one number. A team can be strong on engineering practice and weak on data foundations, or the reverse. Collapsing those into a single verdict destroys exactly the information that would tell you what to do next. Different dimensions deserve to stay separate.

Deferring is a real answer

The most useful output of an assessment is often “not this, not yet”.

flowchart TD
    A["Potential AI use case"] --> B["Consider value and context"]
    B --> C["Review foundations, risk and oversight"]
    C --> D["Suitable to explore now"]
    C --> E["Foundations need attention"]
    C --> F["Defer or retain the current approach"]
    D --> G["Bounded pilot with human review"]
    E --> H["Prioritise improvements"]
    H --> C
    G --> I["Evaluate and revisit"]
    F --> I

This diagram describes a decision-making philosophy, not Compass’s internal rules. Its point is that three outcomes are legitimate. A use case can be suitable to explore now, as a bounded pilot with human review. It can be blocked on foundations, in which case the improvement work is the AI work. Or it can be deferred, with the current approach retained — sometimes because the value is thin, sometimes because the oversight burden exceeds what the team can carry.

Naming a prerequisite is a result. It converts a vague sense that “we’re not ready” into a specific piece of work with a name and an owner. And an explicit deferral, recorded with its reasoning and a date to revisit, is far more durable than an idea that quietly stalls and reappears in six months with nobody able to say what happened last time.

The takeaway

Adopting AI well is less about finding the best tool than about knowing which decisions you are actually making, on what evidence, and in what order. Compass exists to make those decisions deliberate and explainable — to give a team a clear view of its own context, an honest account of its gaps, and a defensible next step rather than a backlog of enthusiasm.

If your team is somewhere between “we should be using AI” and knowing what to do on Monday, the useful move is to assess a real project — one with actual constraints, actual people, and an actual deadline — and see what the context tells you.