Making agents actually reliable
Agents demo well and fail quietly. Tool use, routing, state, guardrails — and a way to measure whether any of it actually works. Brain Grid came out of this one.
Brain Grid is live and in production
VoidMotion Industries · R&D Labs
We don’t take briefs. We take problems.
VoidMotion Industries is an R&D lab. We take hard technical problems apart, build what solves them, and release that as a product — not as a bespoke system built for one client. Brain Grid, our agent orchestration platform, started as a question in Labs. It’s now in production.
Brain GridLive — used directly by businesses
ProductsReleased, not billed by the hour
VMI-LabsWhere every product starts
vmi.lattice
signal
vmi.lattice
—
static mode
R&D is not a project you can finish. The problems worth solving keep moving — so the team working on them has to keep running.VoidMotion Industries · operating thesis
To be clear
An R&D lab, not a development shop.
The difference isn’t tone. It’s what we produce. A development shop sells you its hours and hands back your specification. We research a problem, build the thing that solves it, and release that thing as a product other people can use.
What we do
Solve it, then release it
- Research problems that don’t have a settled answer yet.
- Build the tools and applications that solve them, end to end.
- Release those as products — businesses sign up and use them directly, no integration project.
- Keep operating what we ship, because running a system in production is the only honest source of the next question.
- Take on outside problems, when the pain is real and widely felt.
What we don’t
Build to order
- Take a written spec and implement it to the letter.
- Sell engineers by the hour, the seat, or the sprint.
- Staff augmentation, or sitting inside someone else’s backlog.
- Build something bespoke that will only ever serve the one company that paid for it.
- Take work we think shouldn’t be built — we’ll say so.
If it’s a feature request with a delivery date attached, we’re the wrong team, and we’d rather tell you that in week one than month four.
How this is paid for
Two ways this runs.
01
Products
Businesses subscribe to what we release and run it themselves. Brain Grid is the first, and it’s built to be the first of several.
This is the line that grows without us hiring — the only reason a lab this size can afford to spend its own money on research that might not work.
02
Funded research
A company pays us to solve a problem they have. It looks like engineering; the terms are what make it research.
You get the answer far earlier than you’d reach it alone, at a fraction of solo cost, because you aren’t funding it alone. In exchange, you’re funding something that outlives your own use of it.
What we keep
The right to generalise
The right to build the underlying solution into a general product other businesses can eventually use — because that second and third user is what funds the next question.
What you get
The answer, first
- A working deployment on your own systems, running under your ownership from day one.
- A licence to the resulting tool on preferential terms, fixed in the engagement agreement.
- A head start before any generalised version reaches the open market.
- First refusal on the productised version when it ships.
What stays yours, full stop
Your data and your name
Your data, your specific implementation, and your identity as a client. We generalise the problem and the approach into a product; we don’t carry your business’s specifics with it.
Standard confidentiality terms apply, and are agreed before work begins.
Same filter either way. Is this felt by more than one organisation, and has nobody solved it properly yet? If yes, there’s a product at the end, and a second user to fund the next question. If no — that’s a job for a development shop, and we’ll tell you so.
Roughly what to expect. Funded research starts with a short scoping phase to confirm the problem is real before either side commits further. Scope, duration and cost are agreed at the end of it, on the evidence, rather than guessed at the start.
If your timeline is fixed and short, or your budget is set against a feature list rather than a question, we’re likely not the right fit — better to find that out before either of us spends a week on it.
What that produces
Brain Grid.
The clearest example of the whole model: a problem we kept running into, taken apart in Labs, built into a product, and released for any business to use directly.
brain-grid · agent orchestration
in production
Brain Grid
Agent orchestration for people who don’t write code
Brain Grid turns a written prompt into a working AI agent — built, wired to its tools, running. No pipeline diagrams, no orchestration framework to learn, no engineer required to get from idea to something that does the job.
It exists because building this layer in-house is expensive, and most organisations that need one can’t justify funding the engineering themselves. Brain Grid is that layer, already built and running.
It’s a product, not an engagement — businesses use it directly rather than commissioning us to build one for them. Agencies were simply first to arrive, because they felt the cost of building their own soonest.
Status Live, in production
Access Direct
Scope Industry-agnostic
One prompt in
Describe the agent you want in plain language. Brain Grid handles the construction, the tool wiring and the orchestration behind it.
Built for non-technical teams
The people who understand the workflow are the people who build the agent. No engineering ticket, no handover, no waiting for a sprint.
Not vertical-specific
The orchestration problem itself isn’t industry-specific, which is why the platform could be released rather than rebuilt per client.
On everything else: our products are public — that’s the point of them. Work done with partners on their own systems isn’t, and won’t appear here as a logo or a case study. Brain Grid is what we point at, because it’s the one we can be honest about in full.
Where we go deep
Five problems we keep returning to.
Not a service list. These are the areas where we have running systems and open questions — new Labs work almost always starts inside one of them.
Work that should never have been manual
Every organisation runs some weekly ritual by hand that a machine should have taken over years ago. Automating one company’s version is a job. Finding the shape they all share is a product.
Data that arrives where decisions happen
Getting information from where it’s produced to where someone acts on it — reliably, observably, without a person babysitting a spreadsheet on a Monday morning.
Systems that get exactly one take
Broadcast graphics, live visualisation, interactive installations. Real-time work has no retry: it holds under load in front of an audience, or everyone watches it fail.
Whatever nobody’s answered yet
The category that matters most, and the reason we’re a lab rather than a shop — including the honest cases where the answer is that it shouldn’t be built at all.
The research arm
VMI-Labs
Labs is the front of the loop and the source of every product we release. A problem gets taken apart here, funded by us, before anyone commits to a solution. Brain Grid started as LAB-01. Everything else below is still open.
Labs is funded by us, never billed to anyone. A question that survives here becomes a product the whole market can use — that is the only exit we are interested in.
| Lab | Question | Status |
|---|---|---|
| LAB-01Agent orchestration for non-technical users | How much of building an agent can collapse into a single prompt? | Shipped → Brain Grid |
| LAB-02Evaluation harness for agent behaviour | Can a change to a prompt or routing rule be defended with a number instead of an opinion? | Active → Runs against Brain Grid on every change |
| LAB-03Cost model for inference-heavy products | What does an AI feature actually cost per user, including retries and the long tail nobody budgets for? | Active → Has argued us out of two builds |
| LAB-04Show-control bridge for real-time graphics | Can operators trigger graphics from the tool they already know, with no manual fallback? | Prototype → Ran a live install |
| LAB-05Synthetic inputs for edge-case QA | Can we generate the malformed, adversarial inputs a system will meet in production before it meets them at 2am? | Prototype → In use on two internal pipelines |
| LAB-06Browser-native pipeline visualiser | Can a dependency graph for build and data pipelines run with no server and no install? | Archived → Superseded; folded into LAB-02 |
| LAB-07Creative production at volume | How much of a high-volume creative pipeline can be tooled so that output gets faster, better and more scalable at the same time — not one at the expense of the others? | Active → Workflow rebuilt; tooling in development |
| LAB-08Prompt-driven motion and video editing | Can someone with no After Effects experience describe the animation or edit they want and get it built, with no layers, keyframes or timeline to learn? | Prototype → Early prototype; built for non-specialists first |
How we work
A loop, not a handover.
No final delivery date, because the interesting problems don’t have one. Four phases, running continuously — what Labs proves becomes a product, and what a product learns in the field becomes the next question.
Phase 01
Observe
Real systems, real constraints, what’s already been tried. Most stated problems aren’t the actual problem.
- System & data audit
- Problem restatement
- What is already true
Phase 02
Prototype
The smallest thing that answers the question. Cheap to throw away, and thrown away often.
- Feasibility spikes
- Evaluation harness first
- Kill criteria agreed up front
Phase 03
Productise
What survives gets built properly: tested, observable, hardened enough that others can depend on it without us in the room.
- Production engineering
- Tests & observability
- Documentation as you go
Phase 04
Operate
We keep running it. Watching a system meet reality is the only reliable source of the next real question.
- Run & monitor in production
- Field learnings back to Labs
- Continuous, not closed out
↶ back to observe — the loop does not terminate
Get in touch
Bring us a problem.
Not a brief, not a feature list — a problem. If it’s real, widely felt, and nobody’s answered it properly, we want to hear it. If we’re the wrong team, we’ll say so in week one, not month four.
Worth an email if
You’re funding an answer
- You can’t find another company that’s solved this properly either.
- You’d rather fund an answer than staff a project.
- You’re comfortable with the underlying approach eventually helping others too, in exchange for reaching your answer sooner and cheaper.
Probably not us if
You’re buying delivery
- You already know exactly what to build and just need hands.
- The solution needs to stay entirely proprietary to you, with no generalised version ever.
- The deadline is fixed and short.
If you’re unsure which side you’re on, email us anyway — that’s what the first conversation is for.
[email protected]
Europe · Middle East · Asia Pacific
Remote-first
Replies within two working days