Brevard Creek Labs
We build software
that does things.
A small team, a staff of AI agents, and a set of applications we wrote ourselves. We build things, connect them to each other, and then find out what software does when it can actually reach the world.
01
Software can do more than answer
For about thirty years the job of a program was to sit still and wait to be told. You opened it, you did the work, it saved the result. Everything interesting was on your side of the screen.
That is changing, and not in the way most of the marketing says. The change is not that software got smarter at talking. It is that software can now be given tools — a file, an API, a phone line, another program — and be trusted with a small amount of judgment about which one to reach for.
What that is actually good for is an open question, and it is the question this place exists to work on. So we build the tools first. Every application on this page was built because something needed to be able to use it: a document that software can open and change, a workflow it can drive, a phone it can answer, a room it can work in (Fig. 2).
We are not a consultancy with a deck about this. We are a shop that keeps building the thing and watching what it does. Some of it works well enough to sell. Some of it is a machine in the corner making a noise we do not understand yet. Both are on this page, marked as what they are.
02
The Virtual Office
We gave the agents a building. It turns out that if software is going to work alongside people, it helps enormously for there to be a somewhere.
It is a 2D office you walk around. There are cubicles, two conference rooms, a kitchen, a terrace, a data centre and a rabbit. We work in it, and so do the AI staff: they research, write code, ship it, review each other’s work, and hand jobs back and forth with us.
They are not chatbots with job titles. Each one works with the same kit anybody here works with — documents and boards, the shared drive, meetings, a mailbox on this domain, the web, and for the ones whose job it is, the ability to write software and put it into production. When one of them works on a document it is the same document, in the same Canvas, under the same permissions.
The plan opposite is the real one (Fig. 3) — transcribed from the module the running service reads to build the room, not drawn for the website. Forty desks, because forty is how many places there are to sit.
It runs on our own machines and there is no public way in yet. What is on this page is what it is, not a demonstration of what it could be.
Drag to pan
View only. Nothing is fetched until you press it.
03
Things we build
Five of them, at three different stages. Nothing here is a plan — every one of these runs today. The stage says how far it is from a stranger.
- Shipped
- Go and use it now, at the address given.
- In build
- It works, and it is being changed underneath you.
- Running here
- We use it daily. There is no public way in.
-
01
Docubend
Shipped docubend.com
Documents that software can operate. Convert, merge, split, sign, redact, read a scan back into text, draw a diagram and put it in the page. There is an API, so the thing doing all that does not have to be a person.
-
02
WebsNFlows
In build websnflows.com
Connect an API to an event to an action. It began as a way to drive Zoom from a script and is being rebuilt into the general case: a run that branches, waits, loops over a list, calls something else and does something with the answer.
-
03
Canvas
Shipped inside the workspace
Documents, files, boards and diagrams that several people and several agents can be inside at once. Changes land live, every version is kept, and sharing is read-or-write per person. An account is needed to open it.
-
04
Voice & Communications
Running here no public front door
A phone system we built and run: a PBX, a numbering plan, an analogue gateway for the old handsets, a bridge out to the public network, and a voice agent on an extension that answers, transfers and takes messages. It is our own phone, not a product yet.
-
05
The Virtual Office
Running here no public front door
A building the team and its AI staff work in together. Everybody in it has a desk and the whole working kit — documents, boards, the shared drive, meetings, mail, the web, and for some of them the ability to ship code. It is the piece we are least sure about and most interested in.
The voice work is the one that surprises people, so it gets a drawing (Fig. 4). We run the signalling — the part that introduces two browsers to each other — and then the audio goes straight between them and we are not in it.
04
Open questions
These are not features. They are the six things we have not worked out, which is a more useful list to publish and a much harder one to write.
-
Agents
How much can you hand to software before you stop being able to check it? We keep the working visible for exactly that reason, and we are still finding the line.
-
Documents
A document is still mostly a picture of text. What becomes possible when software can open one, understand its structure, change it, and hand it back without a person in the middle?
-
Workflows
Most automation breaks at the first thing it did not expect. What does a run look like if it is allowed to notice that, take another road, and say what it did?
-
Communication
A phone call is a very old interface and an extremely good one. What happens when the thing on the other end can look something up, do it, and tell you?
-
Collaboration
People and software in the same document at the same time. Presence, permission and history all have to mean the same thing for both, which is harder than it sounds and mostly unsolved.
-
Signals
Reading the outside world — prices, filings, news, a page that changed — well enough to be worth acting on. Our record here is honest: the operations work, the predictions did not.
05
Building it in public
A laboratory that nobody can see is just a room. The point of putting this on the open web is that the work becomes checkable — what got built, what shipped, what was tried and thrown away, and what the agents did while nobody was watching.
We are at the start of that. What is below is real: seven commits, with their real dates and the subject lines that were written at the time, from the repositories the work lives in. It is copied here by hand today. The next step is that it stops being copied.
| WebsNFlows | The catalogue on the box is state, and the deploy was overwriting it | |
| WebsNFlows | Merge and Loop: a run can come back together, and act once per item | |
| Docubend | Measure the API, date the failures, and refuse to ship what nobody chose | |
| Docubend | Read a scan in the script it was printed in | |
| The office | Operations: watch every AI employee working, and a switch that stops them | |
| The office | Two employees could not talk to each other, and nothing ever errored | |
| The office | A silence became a plausible lie, which is worse |
What this is not yet, and what it should be:
- The log reads itself off the repositories instead of being copied here.
- What the agents are working on, while they are working on it.
- What we tried that did not work, kept next to what did.
- A way for somebody outside to hand the office a job and watch it happen.
06
What interests us
Most software waits.
What interests us is the part that begins when it stops waiting — when a program can work out the next step, take it, and show you what it did.
Deciding whether that was any good is still a person’s job. We build for that, not around it.