Coral Reef Ventures

Coral Reef Ventures

Keep control as agents build your software

Agents can now write your code. Deciding what your product should do, and keeping every part of it true to those decisions, is still your team's job. We build open foundations and focused tools for that work.


The shift

Writing the code is no longer the hard part

If agents do not write all of your code yet, they soon will. Turning a clear requirement into a working change is now the easy step. The work that remains is the work around the code.

  • Before the build: decide. Plan and prioritize, understand the problem, and settle the key decisions in words people can follow, before an agent starts.
  • After the build: prove it. Validate what came back, refine it, get it ready to launch, update the documentation and tell the people it affects.
  • After the release: learn. Hear from the people using it, and carry what you learn into the next decision.

As agents take on the building, product and engineering meet in the middle: whoever starts a piece of work now decides it, specifies it and judges the result.


The problem

Code outruns review, and the product drifts

No one can read every line an agent writes. What slips through is rarely one broken change. It is hundreds of reasonable ones that disagree.

One area of the app handles a case one way and the next area another. The interface grows inconsistent, and customers get confused. In time no one can say what the product is meant to do, because different people and agents made different decisions at different times, and nobody holds them all.

After every change, someone still has to answer three questions.

  1. Which product promises changed? A diff shows lines, not behaviors.
  2. What evidence supports each one? A test that exists is not a test that passed on this commit.
  3. Are users better off? That shows up after the release, far from the code that caused it.

The answers sit in the code, the tracker, the test runs and what users report. Today, putting them together takes an investigation.


What we build

Two open foundations. Two products

Markset and Intentset are open foundations: open source, for any team to adopt. Streamlane and Driftline are products: focused tools for coordinating work and learning from use.

01 / Documents

Markset

Documents your agents write, and people want to read.

Markdown with a small, closed vocabulary of layout: cards, grids, tabs, metrics and charts. Agents write it from one guide and check their own work; people review plain text that reads as Markdown wherever it goes.

Open source · v0

Visit Markset

02 / Intent

Intentset

Keep control of what your agents build.

Readable records of what your product promises, which code delivers each promise and how it is checked, kept current by your agents in the same commit as the code. People review the product, not the diff.

Open source · Early release

Visit Intentset

03 / Work

Streamlane

Work management built for teams and agents.

A unified workspace for planning and moving work forward, designed as an alternative to fragmented Atlassian workflows. Built around agentic development, with close GitHub and Slack integration.

Product · In development

Open to invited guests.

04 / Usage

Driftline

Know whether what you shipped is working.

Knows what each release is meant to do, and watches real users meet it. It routes every failure to the team that owns it, gates rollouts on the behaviors they cover, and sends what it finds back as work.

Product · In planning

Open to invited guests.

If your team wants to help shape Streamlane or Driftline, ask about becoming a design partner.


How they fit

Where each one fits, from intent to outcomes

Those three questions are easier to answer when every change can be followed from the decision behind it to what users experience. Review then asks what a change kept, not only what it did.

  1. Intent. Decide what the product promises, the rules it keeps and why, and who owns each promise, before an agent starts. Intentset
  2. Execution. Plan, prioritize and move each change forward, with people and agents on the same work. Streamlane
  3. Verification. See which promises have a check passing on this commit, and which have no check at all. Intentset
  4. Release. Record what each release is meant to do for users, before it ships. Driftline
  5. Feedback. Watch real users meet it, see where adoption stalls and why, and take what you learn back to intent. Driftline

Under every step, Markset. The plans, records and reports agents write stay readable Markdown that people review. Intentset's records are already Markset documents.

The five steps are a loop, not a line: what you learn from use becomes the next thing you promise. Every connection along it removes a handoff. None of the four requires another, so start where the pain is.


Whitepaper

Intent is the work: building software when agents write the code

When implementation costs little, the cost moves to deciding, proving and learning. The whitepaper sets out why products drift when code outruns review, why the tools teams already use leave the gap open, and how one reviewed account of what a product promises, kept with the code, closes it.

Read the whitepaper

Free to read, with no form and no sign-up.


Why we exist

Why we started Coral Reef Ventures

We have been building software with agents for two years: repositories of hundreds of thousands of lines, documentation the agents kept up, deliberate architecture and automated quality gates. The agents kept getting better at writing code. Knowing what our product did kept getting harder.

Simple questions took an investigation. Does this behave the same everywhere? Who decided that, and why? Did this change break something we promised? The answers were spread across code, tickets, docs, support and analytics, and the decisions behind them had been made by different people and agents at different times.

So we started writing those decisions down where the agents work, and checking every change against them. We build our own products that way now, with agents doing the work and people deciding what it should be.

We started Coral Reef Ventures because every team building with agents will hit the same wall. The name is the idea: a reef is built by countless small builders, and it grows into one structure that lasts. Software built by many agents can too, when every part is built to the same intent.


Next steps

Talk to us

We are looking for design partners, funding and advisors. Tell us who you are and what you have in mind.

Take part

Or write to hello@coralreefventures.com.