See what your agents are building.Carry the context forward.

See which features your team is building, what’s been completed, and where coding session time is spent. Carry decisions, findings, and next steps across developers and coding agents, so each new session builds on what your team already knows.

Works with every coding agent your org runs

Reads Claude Code, Cursor, Codex, Copilot, Amp, Gemini CLI and more.
The loop

The shared brain for every coding agent, and every developer, inside one organization.

  1. 01MachinesThree developers, three machines, three different coding agents.
  2. 02ThreadsEach one is carrying a different piece of work, and each thread lives only on the machine that made it.
  3. 03SyncA read only collector reads what each agent already writes to disk and syncs it to Loopmason.
  4. 04ShareLoopmason keeps one shared context for the team instead of one stranded copy per machine.
  5. 05In syncSo every machine has every thread, whoever opened it and whichever agent they run.
05 · In sync

So every machine has every thread, whoever opened it and whichever agent they run.

each machine · its own thread
every machine · every thread
priyaClaudepriya.localCheckout flow
sofiaCursorsofia.localBilling migration
kenjiCodexkenji.localSearch relevance
Loopmasonone shared context
read only · nothing executed
priyapriya.localCheckout flowownBilling migrationsofiaSearch relevancekenji
sofiasofia.localCheckout flowpriyaBilling migrationownSearch relevancekenji
kenjikenji.localCheckout flowpriyaBilling migrationsofiaSearch relevanceown
Use case

See the work.
Not just the output.

See what’s in progress and what’s been tried, and carry what your agents learn across sessions and threads.

In progress

Know what's moving.

See the task and the latest recorded activity across developers and agents, not just a list of open sessions.

Latest session activityIn progress

Fix duplicate payments

CTO
priyapayments-api
Concurrency test failed · 2 min ago

Fix flaky deploy pipeline

DevOps
kenjiinfra-pipelines
Rollback triggered after 3rd failed deploy · 8 min ago

Debug feature store staleness

ML
sofiafeaturestore
Backfill traced to a stale partition · 22 min ago
Attempts & findings

See what's already been tried.

Follow attempted fixes, recorded results, and open questions, not just the final diff.

Already tried, across the teamThis week
✕

Disabled the pay button after the first click (FE)

CTO

Didn’t work: a slow connection let people click it again.

✕

Checked for a duplicate charge before saving (BE)

CTO

Didn’t work: two requests still landed at the exact same instant.

✕

Gave the deploy more time to start up

DevOps

Didn’t work: it still failed under heavy traffic.

?

Ran the data refresh again

ML

Still unverified: the numbers came back just as out of date.

priya · kenji · sofia
Context across sessions

Start with what's already known.

Carry decisions, failed approaches, and next steps across sessions and threads, even when the developer or agent changes.

Fix duplicate paymentsContext from 2 sessions
✓

Decision

Proceed with a shared idempotency key. The fix still needs verification.

✕

Already tried

An in-memory lock failed across multiple workers.

→

Next step

Run the concurrent-retry test against the fix.

Sources preserved with the context

priya · Claude Code · Session 123
kenji · Codex · Session 456
Time by thread

See where session time goes.

Explore recorded session time by task, with the underlying sessions available for context.

Recorded session timeExample week
Duplicate payments4h 20m
Flaky deploy pipeline2h 40m
Feature store staleness1h 50m
Checkout timeout40m
Total across these threads9h 30m
Summed elapsed session time, not human effort. Concurrent sessions may overlap.
Shared context

Every session starts cold. Construct the loop instead.

Every agent meets your codebase as a stranger. It rereads the repo, rederives the decision and retries the approach that was already thrown out, because the reasoning from last Tuesday ended with the session that produced it. Multiply that by every developer, every tool and every machine, and an organization relearns the same thing dozens of times a week. Loopmason listens, groups and serves it back.

  1. 01
    Listen

    Every agent, not just the one you standardised on.

    A read only collector reads the session logs each coding agent already writes to disk and normalises them into one vendor neutral schema. No source code is read and nothing is executed.

    Claude CodeCursorCodexCopilotAmpGemini CLI
    four agents, four developersread only
    priya
    sofia
    kenji
    sana

    One schema

    vendor-neutral stream
    4 agents → 1 format
  2. 02
    Group

    Three developers build different parts of the same feature, each using a different coding agent.

    Sessions are correlated by repo, code region and time window, so work on the same feature arrives as one thread instead of three private transcripts nobody can see across.

    Grouped across agents and across developers, the part no single tool can do.
    payments-api · repo + region + window1 thread
    priya
    sofia
    kenji

    checkout redesign

    one shared thread
    3 devs · 4 agents
  3. 03
    Serve

    The next developer starts where the last one stopped.

    The thread becomes context the next agent can read, whoever opens it, whichever tool they use. Scoped to the code they are touching, not pasted into every session.

    Available in the next invocation, not next week’s digest.
    sofiapayments-api · new session
    fix staging timeouts on checkout
    loopmason contextservices/checkout/server.ts

    The load balancer was closing connections faster than the app expected.

    priya · Tue 02:14 · never committed

    Ruled out already: DB connection pool size, downstream retries.

    kenji · Wed 11:02
Visibility meets shared context

What one session discovers, the next can use.

Understand what your agents are building, and give the next session the decisions, findings, and next steps it needs to keep going.

Session AFindings & decisions
→
Session BContext to continue
The collector

Install it once. It covers every agent on the machine.

Install the collector once on each developer’s machine. No separate setup is required for individual coding agents. The collector is read only and never runs commands or writes to your repositories.

developer machineread only
+16L

One background process reads every agent on the machine.

Claude CodeCursorCodexCopilotAmp+16 more agents
FAQs

The ones that decide it.

What can I see in Loopmason?
See what your team is building or investigating, what has been completed, and where coding session time is spent. Related sessions are grouped into threads around a feature, bug, or investigation, connecting work across developers and coding agents.
What context can my team reuse, and how?

Reuse decisions, attempted solutions, experiment results, and next steps recorded in coding sessions. This can include architecture choices, bugs investigated, fixes tested, performance improvements, ML algorithms evaluated, accuracy achieved, and insights about datasets, along with why an approach was chosen or ruled out.

Your coding agent can retrieve relevant context through the Loopmason client. You can also copy context from a thread into another agent. Links to the original sessions let you check the details behind each finding.

What do developers need to install?
Install the Loopmason client once on each developer’s machine. It includes the collector, skill, and MCP connection, so supported coding agents can contribute sessions and retrieve shared context without separate setup.
Can the collector change our code or run commands?
No. The collector is read only. It does not scan your source tree, run commands, or write to your repositories.
Which coding agents are supported?
Loopmason supports Claude Code, Cursor, Codex, GitHub Copilot, Amp, and Gemini CLI. If your team uses another agent, tell us during signup so we can confirm support.
What does the time shown in Loopmason represent?
It represents recorded coding session time associated with a thread. It does not measure a developer’s working hours or productivity. Sessions running simultaneously may overlap.
Where is our data stored, and who can access it?
You can use Loopmason’s managed cloud or discuss a deployment within your own infrastructure. During pilot setup, we confirm where data is stored, where AI processing happens, and who can access individual transcripts and shared context.

See what your agents built this week.

Loopmason is in early access. We are running pilots on one repo at a time, with the collector read only and the data wherever you want it. Tell us what your team runs and we will show you your own sessions.