In Parallel
The Shared Context Layer for Enterprise AI
188 followers
The Shared Context Layer for Enterprise AI
188 followers
In Parallel continuously maintains a shared understanding of your organization.
As work happens, it keeps goals, decisions, ownership, risks, and progress up to date, giving both teams and AI a trusted operational picture of what's actually happening. Connect Claude, ChatGPT, Copilot, and other AI tools through MCP, with enterprise-grade security including EU hosting, permission-scoped access, GDPR, ISO 27001, ISO 42001, and SOC 2 Type II.
This is the 2nd launch from In Parallel. View more
In Parallel MCP
Launched this week
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.
Free Options
Launch Team / Built With
In Parallel
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? 👇
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?
In Parallel
@franz_briones 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?
@kristian_luoma 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!
In Parallel
@franz_briones Thank you!
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?
In Parallel
@noctis06 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?
In Parallel
@noctis06 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.
every "single source of truth for the org" tool I've seen eventually turns into the thing everyone stops updating, then it's worse than no source at all because people trust a stale answer. how does In Parallel keep goals/ownership actually current without someone manually maintaining it, is it pulling straight from where the work happens (tickets, docs, calendars) or does it still rely on people logging updates
In Parallel
@omri_ben_shoham1 yes. that's the problem we're solving! I agree, no new interface or tool will help.
Question about the write path. Everything in the thread so far is about agents reading the shared picture, but keeping context current as work happens implies agents and integrations are also writing observations back. Once several agents can write, the trusted operational picture has a provenance problem: how do you label and weight agent-generated context against human decisions, so one confidently wrong summary does not become the context every other agent inherits? Is there a review gate, a provenance tag per entry, or a decay rule for unconfirmed observations? This is the part I would pressure-test before wiring it into every tool, and I could not find it discussed yet.
In Parallel
@cipherslice Yeah, great point. There's a gate for sure, we call it the change log. The balance however is how not to make it annoying to deal with the increasing amount of approvals. We set some rules for auto-approvals (on user consent, much like you do things in the ChatGPT/Claude sessions). For the provence: absolute key, we have reference on the origins for the observations at all times.
Decay too exists, although it is context-dependant, and that is something we're hoping to evolve further.
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?
In Parallel
@abdullah_javaid3 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).
@kristian_luoma 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.
@kristian_luoma 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.
In Parallel
@abdullah_javaid3 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!
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?
In Parallel
@priya_kushwaha1 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).