In Parallel MCP - Your context, available to every agent.

byβ€’
You've explained your company to ChatGPT. Then to Claude. Then to Copilot. Every time you open a new chat, you start from scratch. Paste the notes. Upload the document. Copy in the email thread. Summarize what your team decided two weeks ago β€” to a tool that could've just known it all along. In Parallel's MCP server ends that. Connect it once, and whichever AI you open already knows your meetings, decisions, and context. Just ask the question. Less prose. More truth.

Add a comment

Replies

Best

Okay, as promised, I'll go first πŸ˜…


Mine was a weekly "alignment sync" that survived three reorgs. The project it was created for shipped in 2023. Nobody remembered why it existed, but nobody wanted to be the one to kill it β€” so every Monday, eight people spent 30 minutes confirming there was nothing to align on.


It finally died when someone noticed the original organizer had left the company a year earlier.


That meeting is basically why In Parallel exists. If the decisions and status lived somewhere that updated itself, the meeting would have had nothing left to do.


Your turn β€” what's yours? πŸ‘‡

Really interesting approach to the LLM memory bottleneck standard custom instructions are too static, and vector databases get too noisy. Does your self-hosted VPC setup allow us to restrict sensitive context folders so only specific teams (like HR or Finance) can query them?

Β Thanks so much, couldn't agree more. We do not at the moment offer VPC setup, but are working on that option; what is important is that we offer no-training on your data (ISO 42001 certified, and SOC2 compliant).

SOC 2 Type II for an MCP context layer is exactly the boring enterprise signal I'd look for

Β 100%. Not only that, we got also ISO 42001. While not as hot yet, I'd say it'll be the future. If interested, here's some more boring stuff:

As a CPO this hits a nerve πŸ˜… The gap between "what we decided in the room" and "what's actually on the roadmap" is where half my week disappears. Every tool captures something β€” notes, tickets, docs β€” but the decision itself always seems to fall through the cracks. Love that In Parallel sits underneath instead of adding yet another surface to babysit. Pricing per workspace instead of per seat is the right call too. Congrats on the launch, upvoted πŸš€

πŸ’Ž Pixel perfection

Congrats on the launch, Kristian! The concept of standardizing the shared context layer over MCP is brilliant. A major pain point with centralized team hubs is 'context drift'β€”a decision is made in Slack, the execution changes in GitHub, but the overarching context file stays static. How does In Parallel natively capture those micro-updates without forcing team members to manually edit the shared state every single day? Is it passively listening to integrations?

Β Yes, indeed. Passively listening, and analysing, de-duping, and collecting "observations" is the key. We've been inspired greatly by the works of John Boyd (an American fighter-pilot from Korean War who came up with the theory behind "Situational Awareness"). Context drift is such a great term. We use Coordination Tax, but I'm tempted to steal "Context drift". Did you coin it?

Β Haha, feel free to steal itβ€”it’s officially open-source now! It just perfectly describes that silent drift where reality moves forward but the documentation stands still.

Love the John Boyd / OODA loop inspiration. Passively collecting and de-duping 'observations' is definitely the right architecture for this. If an organization can shorten its loop of capturing reality and feeding it to agents, it’s an immediate unfair advantage. Stoked to take this for a spin!

Β Thank you!

One thing that would make this a no-brainer for me is a mobile companion app. Most of my context-switching happens away from my desk, and being able to quickly check on goals, risks, or ownership changes from my phone would keep me aligned even when I'm not at my laptop. A simple read-only view with the ability to flag updates would be enough.

Β .. did you just read our roadmap? Working on it!

This bit me two weeks ago, a rule I set at planning stage silently disappeared before the generation step and the output invented a fact. Took a day to find where the context died. So, real question: two agents pull the same context, one updates it mid-task, what happens? Last write wins or something smarter?

Β yeah, I hate when that happens. Well, we're building and maintaining decisions-based context that is the artefact e.g. something that can work for between people, not just between sessions. But to pull that off it is something smarter: so we save the "graph" of events and relationships, and use that.

Β Saving the graph instead of raw context answers it, yeah. "Between people, not just between sessions" is the part I'm going to sit with, my per-client fact bases are still session-shaped and that's probably a ceiling I haven't hit yet. Thanks Kristian.

The portability problem is the real one: context trapped in each tool means every agent is a stranger. Building on MCP is the right bet because it standardizes that layer instead of locking it to one app. The test will be keeping context fresh, stale shared context is worse than none.

Β Amen.

Every comment here is about big teams so let me ask from the other side. I am a one person company and I still lose context between Claude Code sessions every single day. Is this built only for organizations or does it make sense for a solo builder too?

Β I feel your pain. By default, you are managing your own context in the product. By extension, we let you share it with the team (or agents, if needed).

Β That answers it, thanks Kristian. I will hook it up to Claude Code this week and see how it feels for a team of one. If it saves me the daily context paste I will be back with a review.

Β Circling back, and not with the review I promised, because I could not get in.

You said the default is that I manage my own context, which read like a team of one was fine. Signup rejects personal email addresses though. Gmail, Outlook and iCloud all bounce to a request an invite screen, and it wants a work domain to open a workspace. I am a one person company on a Gmail, so that is where it ended for me.

Flagging it because I asked you the solo question right here in this thread and your answer sounded like yes. Anyone who reads it and goes to sign up meets the same wall. Either solo is not the market yet, which is completely fair and worth saying plainly, or the gate is stricter than you meant it to be.

If it helps, the fix is probably one line on the signup screen rather than anything in the product. Something like In Parallel runs on company workspaces, you will need a work email. I would have known in two seconds instead of finding out at the end.

Not a complaint at all, I just did not want to go quiet after saying I would try it. If the personal email path ever opens up I will pick this back up. The daily context paste is a genuine problem for me and I still think you are pointed at the right thing.

Β Thank so much for a thorough report, and the feedback. You are absolutely right, and I did not obviously mean to mislead you - but I forgot the design choice we did with "personal" emails. I'll add this to the roadmap, and come back. Thanks again!

The "explain your company once and every agent already knows it" pitch nails the actual daily tax of re-pasting context into each new chat. Where does that shared context actually live: a hosted store on your side, or something I control and can host in my own environment? And how does it stay current: does it auto-derive decisions and ownership from the connected tools, or does someone have to curate what goes in? With permission-scoped MCP access, is scoping per-user so an agent only sees what that person could see, or is it one org-wide context every connected tool can read?

Β Great question. We're not doing an org-wide context in the sense, that we'd integrate to tools and try to figure out what is the right access model. Rather, we let managers bring their tools and aggregate the context for them, and shared workspaces, based on the access. Shared workspaces can be shared even org-wide, but the control is key (at least that's what we think!). We're in the future working to have more and more ambient/automatic ways to share context - e.g. "to a parent org", or to a "dependency" etc - but we want to make sure that user stays in control.

Workspace-scoped rather than org-wide inference makes sense β€” the manager decides what gets pooled instead of the tool integration guessing. What I'd want to know before wiring my stack in: once context has been aggregated into a shared workspace, is it a live view that re-derives from the source tools, or a snapshot? Concretely, if someone loses access to the Notion or Jira project it came from, does that context drop out of the workspace, or does the copy keep serving to every agent that can read the workspace?

Β Yup, we think so too.

The shared context is a continuously maintained (based on events, and cron). So droppign Notion or Jira may mean that we lack future updates, but the "current reality" is kept as it is.

The events+cron freshness model makes sense, keeping current reality even if a source drops is the right default. The piece I still can't place: with permission-scoped MCP access, is scoping per-user so an agent acting for me only surfaces what I could already see, or is it one org-wide context every connected tool can read? For anything with HR or finance in the graph, that boundary is the whole ballgame.

12
Next