With or Without — The Case for Grounded AI

It is 10:42 on a Wednesday in Helsinki. Jane, a programme lead at a mid-sized industrial group, opens Claude between meetings and types six words: how are my projects doing?

She gets back something fluent, structured, and wrong. The assistant has read her calendar and two Slack channels. It tells her two programmes look fine, and one might be at risk. She knows, because she sat in the steering committee on Friday, that the risk it has flagged was closed out three days ago and that the programme it called fine has just lost its critical-path engineer.

Two desks down, Filip asks the same question. His assistant has the In Parallel Shared Context Platform connected. It answers from the plan state itself — what shifted on which programme since the last review, which decisions still have downstream commitments open, and the two risks the team has been working on but not yet logged in the steering deck. The summary is shorter than Jane’s. It is also right, accurate, and precise.

Same model. Same prompt. The difference is what is underneath.

The wrong axis

Most discussions of AI in the workplace are still organised around the model. Which one is best at coding? Which one is the cheapest per million tokens? Which provider to default to next quarter? This has been the wrong axis for at least the past year, and a year from now, no serious buyer will be holding the conversation in this form.

Frontier capability has converged to a shrinking band; the leaders trade places quarter to quarter; price keeps falling; deployments increasingly assume the model is a swappable component. We have heard variations of “we’ll use Claude for now and move to whatever is cheaper on Bedrock next quarter” more than once in recent customer conversations.

That is not a complaint. It is a description of where the value is going.

The value is moving to the layer that decides and delivers what the model knows.

Call this the grounding problem for very capable frontier models. A model can be brilliant in the abstract and useless in your work. Its eloquence is a feature of training; its usefulness, on the day, depends almost entirely on the context handed to it. If that context is a stale handful of integrations and the last forty Slack messages, the assistant will guess fluently.

If it is the preprocessed causal thread between meetings, decisions, and outcomes — the substrate the company actually runs on — the AI tools now will answer from reality and keep the derivative work grounded.

The claim, plainly

The same assistant becomes roughly an order of magnitude more useful when it is working from your reality instead of guessing at it.

We have arrived at the rough magnitude by watching what stops happening when the substrate is present. The conversation no longer opens with a paragraph of disclaiming hedge. The answer no longer needs to be cross-checked against the live source. The user no longer has to translate between what the assistant said and what the team has actually been doing.

The 10× is not in volume. It is in relevance.

This is the second important distinction. Other connectors offer the assistant more data — more documents, more messages, more rows. More data without grounding is just a larger field for the assistant to be wrong inside. Grounding is something different. It is the difference between an assistant that has read your inbox and one that has read your week.

Three things that change

When an assistant is grounded in shared context, three things start to change in the work, in roughly this order.

It stops generating the obvious. Most AI output today restates what was already in the prompt, slightly reorganised. With proper grounding, the assistant starts surfacing the non-obvious — a contradiction between two commitments made in separate meetings, a risk that has appeared in three programmes without being named in any one of them, a decision whose downstream tasks were never picked up.

Drafting work compresses. Status reports, board updates, executive summaries — anything whose content already exists somewhere in the organisation and just needs reassembly — collapses to a one-line request. Not because the model got better. Because it can now read the actual record.

Reviews start at the decision, not the recap. A management routine grounded in shared context does not need its first fifteen minutes to figure out where the team is. The plan, the changes since last time, the open questions and new learnings are already on the page. The conversation starts where it should — at what to do next.

How it actually works

The In Parallel MCP exposes our Living Execution Plan and the shared context underneath it. The plan is regenerated continuously from signals the team already produces — meetings, commitments, dependency changes, decisions logged in tools you already use — so what the assistant reads is what is actually live, not last week’s snapshot.

To switch it on, you install In Parallel, connect your sources, and in Claude open Settings → Connectors → Add custom connector. Paste the MCP URL. Authenticate. Then ask the question Filip asked.

What this does not do

We are wary of the genre of launch post that ends with the product solving everything, so:

This does not make a badly run programme well run. If the underlying meetings are not deciding or debating things, no substrate can make decisions to ground the assistant in. The In Parallel MCP makes a competently run programme legible to AI. It does not make an absent one present.

It does not replace the project tools. Linear, Jira, Notion, the spreadsheets — they still hold their parts of the world. Many existing workflows and processes rely on established systems of record. Shared context sits underneath them and reads the same signals. It’s a new type of component in the restructure of the fabric of the company, and how it runs. Shared Context will give a new opportunity for new processes and playbooks as information is routed and synchronized in a novel way, in real-time.

It does not make every model good, nor does it make every tool better. A weaker model with great context still has a ceiling. The point is narrower: within the band of frontier-quality models, the assistant’s usefulness on your work is decided by what is underneath it, not by which one you picked. But it will bridge your talent and teams to the tools, models, and systems your organization runs on. The earlier you start with shared context, the more relevance and value you accumulate and compound.

What changes from here

A year from now, “which model” will be a footnote in the vendor selection. The real choice will be which grounding context layer the company runs — what its assistants are actually allowed to know, and how that knowledge stays current as the work moves.

We have built our system of shared context, in the open, on a protocol designed for this. And it is live in customers’ hands today.

— Markku & Kristian · In Parallel · Helsinki · June 2026