Skip to content
Ashlar Labs
Pre-launch · design partner phase

Two orgs.
One investigation.

Ashlar Workspace is the collaborative workspace your support tickets pretend to be.

Get in touch See how it works

I. The problem

Mountains of Data
Dozens of tools
No fast and safe way to share information

Engineers on both sides trickle updates into a ticket. Eventually someone opens a conference bridge and everyone watches one engineer share their screen. Progress is slow and painfully single threaded.

∴ Tools were built for one organization at a time.

Two masonry towers labeled vendor and customer, each with stratified internal context (tickets, internal docs, slack threads, engineer's memory; incidents, architecture, cluster logs, engineer's memory), connected only by a thin low-bandwidth ticket line

II. Why now

AI changes the math.

Before

A dense stack of context layers on the left converges through a single human bottleneck in the middle, with one thin line continuing to a sparse receiver on the right

To update a ticket, a human needs to convert raw context into something readable by another human. This process is slow and lossy.

Now

A dense stack of context layers on the left connects through six parallel channels that pass through a central shared workspace block, with an agent node on each side, to a matching dense stack on the right

Agents read raw structured context directly. Cross-org context is suddenly worth exchanging on its own. The tooling to exchange it is suddenly worth building.

III. The product

What Ashlar Workspace is,
in three pieces.

fig. ii the workspace

01

Peer workspace

Vendor and customer write to the same workspace with equal permissions. Scope (Private, Org, Global) and sensitivity (normal, confidential, secret) are orthogonal, so you can keep something internal while still working in the shared space.

02

Bring your own AI

The workspace exposes itself as MCP tools. Drive it from Claude Code, Claude Desktop, or any MCP client. We don't bundle a model. Your data stays on your side of the contract.

03

Bilateral governance

Nothing crosses the boundary without acknowledgment from both sides. Server-side DLP runs at every promotion. The audit log is hash-chained and exportable. Policy is a first-class engine, not buried in code.

IV. The founder

Built by an engineer
who lived the problem.

I run support engineering for a vendor selling to technical customers. The architectural precursors originated there — revenue growth has vastly outpaced our team because we scale with tooling instead of headcount. Now I'm building the platform standalone. Working demo this summer.

Will Krause · linkedin.com/in/williamkkrause

V. The invitation

See it before it ships.

Talking to design partners and early hires. If you have strong opinions about how enterprise vendors and their technical customers should work together, even better.

Get in touch