Why We Built Plurilog Around One Shared AI Conversation

The problem was not having too many tabs

Closing a few browser tabs would not have fixed the underlying issue.

The real problem was fragmented context.

A conversation with an AI is rarely just the first prompt. Over time, it accumulates information:

• what you are trying to accomplish;
• documents and images you have provided;
• corrections you have made;
• decisions already reached;
• constraints that emerged later;
• useful points from earlier responses;
• questions that remain unresolved.

That accumulated context is often what makes later answers useful.

Once a task is divided between separate AI products, however, that history fragments with it. One model knows something another does not. Files have to be uploaded again. Relevant answers have to be pasted between windows. The user becomes responsible for manually synchronising the discussion.

Multi-model AI should not require the human to act as middleware.

Putting several models on one screen was not enough

There is an obvious way to build a product involving several AI models: send the same prompt to each of them and display the outputs next to one another.

Technically, that is relatively straightforward.

It also was not what we wanted to build.

Plurilog is designed around a different idea: the models participate in the same ongoing discussion.

That distinction matters.

If ChatGPT has already raised an important concern, Claude can respond to that concern. If Claude identifies a weakness in the reasoning, Gemini can address it. If the user corrects an assumption, that correction becomes part of the discussion going forward.

The interaction does not have to restart every time another model speaks.

Those requests only make sense if the models are participating in a common conversational context.

That is the difference between access to several AIs and an actual multi-model AI conversation.

The discussion has to be the source of truth

This creates a less visible engineering problem.

ChatGPT, Claude and Gemini are different systems operated by different providers. They do not naturally share a conversation with one another. Each provider has its own way of representing messages, instructions, files and conversational state.

So Plurilog cannot simply rely on one provider's native chat history and expect another provider to understand it.

Instead, the discussion itself has to belong to Plurilog.

When a model is asked to participate, Plurilog assembles the relevant shared context and presents it in the form that model needs. The objective is that each participant responds to the same evolving task rather than to an isolated version of it.

That architectural idea was one of the most important decisions behind the product.

A recent outside analysis of Plurilog described this as the real challenge of multi-model AI: not simply routing a request to several providers, but maintaining a trustworthy shared context between them. That is a fair description.

The visible chat interface is only the surface. The more important question underneath it is:

What does every model know when it answers?

Shared context changes the unit of work

Traditional AI chat tends to make the prompt feel like the basic unit of work.

But real tasks are rarely one prompt long.

A research task might contain source documents, objections, corrections and several rounds of analysis. A product decision might involve customer feedback, technical constraints and conclusions already reached. A writing project might evolve through outlines, drafts, criticism and revision.

In that kind of work, the useful unit is not the individual prompt.

It is the discussion as a whole.

An external analysis of Plurilog made a similar point, describing the richer unit of work as something closer to a “case file”: the goal, source material, decisions, model responses, objections and constraints together.

That framing closely matches how we think about Plurilog.

The conversation should become a persistent workspace around the task.

Why disagreement is useful

Plurilog is not built on the idea that three AIs agreeing with one another somehow proves that an answer is correct.

It does not.

AI models can make the same mistake. They can inherit a faulty assumption from the conversation. They can be persuaded by a confidently stated claim. And several plausible responses are still not a substitute for evidence.

The value of multiple perspectives is not automatic truth.

It is visibility.

A single polished AI answer can conceal uncertainty surprisingly well. Introduce another capable model into the discussion and different things may happen:

• it may agree but supply different reasoning;
• it may notice an omitted constraint;
• it may challenge an assumption;
• it may interpret ambiguous evidence differently;
• it may identify something neither the user nor the first model considered.

That disagreement can be more useful than consensus.

Elma's analysis makes the same caution: models responding to one another can also reinforce a bad claim, so agreement should not be treated as independent verification.

We agree.

The point of Plurilog is not to manufacture consensus. It is to make more of the reasoning visible so that the human can make a better-informed judgement.

Why we call it an AI panel

The word panel captures the product better than many technical descriptions do.

Imagine asking several knowledgeable people for help with a problem.

There is a major difference between:

• interviewing each person separately without telling them what anyone else has said; and
• putting them around the same table and allowing them to hear the discussion.

In the second case, one participant can question another. Someone can add missing information. An objection can change the direction of the conversation. A later contribution can build on something useful that emerged earlier.

That is much closer to the experience we wanted.

Plurilog is an AI panel because the participants are not simply producing isolated outputs. They are contributing to one evolving discussion.

Files make shared context even more important

The problem becomes more obvious when the task involves more than text.

People increasingly use AI with:

• PDFs;
• reports;
• screenshots;
• photographs;
• presentations;
• research material;
• other working documents.

If you are working across several separate AI products, those materials become another thing you have to manage manually.

Upload the file here. Upload it again there. Explain which page matters. Paste a correction into another conversation. Discover later that one model was working from an earlier version.

That is precisely the kind of friction a shared workspace should remove.

Plurilog supports files and images as part of the discussion so that the user's work can remain centred on the task rather than on repeatedly reconstructing the context.

And this is where the question of shared context stops being an abstract technical concern.

If different AI models are supposed to reason about the same problem, they need access to the relevant information behind that problem.

An outside analysis of Plurilog correctly points out that multimodal work raises the stakes considerably: differences in how a file is parsed, represented or supplied can influence the models' responses.

That is an area we expect to keep improving as the product develops.

The user should still be in control

There is another reason we did not want Plurilog to behave like a black-box “AI council” that automatically decides everything on the user's behalf.

Different tasks benefit from different arrangements.

Sometimes you want all three models involved.

Sometimes you want one model to answer first and another to respond afterward.

Sometimes you want Claude but not Gemini.

Sometimes you want ChatGPT to take the lead.

Sometimes one response is enough.

Plurilog therefore lets the user control the panel: which models participate, who responds and how the discussion proceeds.

The goal is not to maximize the number of AI responses.

The goal is to make additional perspectives available when they are useful.

One subscription instead of three separate workflows

There is also a much simpler practical reason behind the product.

People interested in several leading AI models have traditionally had to maintain separate accounts, interfaces and sometimes separate subscriptions.

Even after paying for them, they remain separate environments.

Plurilog brings access to ChatGPT, Claude and Gemini into one place under one Plurilog subscription.

But we do not think the main value is simply bundling access.

If that were all Plurilog did, it would still leave the most annoying part of the workflow untouched.

The value is that those models can participate in the same work.

What Plurilog is not trying to do

We are deliberately not positioning Plurilog as a machine that turns three AI responses into guaranteed truth.

Nor do we believe every trivial question requires three models.

If you want to know how many tablespoons are in a cup, involving an entire panel would be absurd.

Multi-model discussion becomes interesting when there is something worth examining:

• a difficult decision;
• uncertain reasoning;
• research that needs scrutiny;
• a document that can be interpreted several ways;
• a technical design with trade-offs;
• a piece of writing that benefits from criticism;
• a problem where missing one assumption matters.

The human still determines what to trust and what to do.

The AI panel exists to broaden the reasoning available to that person, not to replace their judgement.

Why this matters as AI models keep changing

The AI market moves extremely quickly.

A model that is strongest for one kind of work today may not be six months from now. Providers release new generations, change capabilities and improve different parts of their systems at different rates.

That makes us increasingly interested in the conversation layer above the models.

The enduring part of someone's work should not have to belong to whichever AI provider happened to receive the first prompt.

The task, the files, the decisions and the discussion should remain coherent even as different models participate.

This is one reason we think multi-model AI will become less about switching between model interfaces and more about orchestration: maintaining the workspace while choosing which intelligence to bring into it.

Elma's article reaches a similar conclusion, arguing that the orchestration layer itself may become the defining product rather than simply the list of providers available in a dropdown.

That is much closer to how we see the opportunity.

What we are building toward

Plurilog is still evolving.

There are many things we want to make better: how shared context is managed, how files are handled, how clearly the discussion shows where an idea originated, how users control the panel, and how naturally multiple models can participate without making the experience noisy.

But the principle underneath the product is unlikely to change.

We do not think the future of serious AI work is simply choosing one model and remaining permanently inside one provider's ecosystem.

And we do not think the answer is opening several tabs and manually carrying the same task between them.

We think there is a more useful model:

one workspace, one evolving discussion, and multiple AI perspectives available inside it.

The conversation should remain coherent even when the intelligence participating in it changes.

That is why we built Plurilog.