Kreativloops is the research and development arm. It brings the software and AI practice: models, agents, retrieval over company data, the platforms they run on, and the evaluation work that decides whether something is fit to ship. Kreativloops builds and operates every system VissionLink puts in front of a customer.
VissionLink Lab
The workshop behind the platform.
VissionLink Lab is the research and development programme run jointly by Kreativloops and BMR. It builds the AI we use in-house before we sell it, designs and prints the hardware we put our name on, and maintains the one flow we use to take an idea all the way to a deployed product.
Two houses, one bench
The Lab exists because neither side could do this alone. One builds the systems, the other runs a business that has to live with them.
BMR
Brings the operating floor: a live rental business with real fleet, real customers and real deadlines. Every prototype the Lab builds gets tested against a working day here first, which is the difference between a demo and something a company can run on.
VissionLink Lab is a joint research programme of two independent companies. It is a way of working together, not a separate legal entity, and we would rather say that plainly than let a name imply otherwise.
What the Lab works on
Three tracks, chosen because each one removes a dependency we would otherwise be renting from someone else.
01
AI we build ourselves
Assistants, agents and automation built in-house, run on our own operations first, then offered to clients once they have survived contact with a real business.
- Assistants that answer from your catalog, pricing and policies
- Back-office automation between the systems you already run
- Evaluation harnesses written before the model, not after
- Deployment on infrastructure we control when the data cannot leave
02
Hardware with our name on it
Proprietary products designed, printed and assembled by us, so a change takes an afternoon instead of a supplier quotation and a six week wait.
- 3D printed enclosures, mounts, jigs and fixtures
- Robotics: chassis, actuation, on-device behaviour
- Boards and firmware reporting to the same platform your staff uses
- Design files and revisions kept in-house, not locked at a vendor
03
A process that comes out of the box
The method itself is a deliverable. One flow covers software and hardware, so a team does not have to invent a way of working every time the work changes shape.
- Ideate, design, prototype, build, deploy, in that order
- The same gates whether the output is a screen or a printed part
- Written down, so a new person can pick it up on day one
- Handed over to client teams, not kept as a trade secret
One flow, software or hardware
Most teams have a process for code and no process for anything physical, so hardware work turns into guesswork. These five stages run the same either way, with a different artefact at each gate.
Ideate
Frame the problem and the constraint that actually binds it, then agree the smallest thing worth testing. Nothing gets designed until we can say what it would take for this to be a bad idea.
Software
The job the user is hiring the system for, and the data it would need to do it.
Hardware
Where the unit lives, what it must survive, and what it costs to make one.
Design
Decide it before building it. The expensive mistakes are structural, and structure is cheap to change while it is still a drawing.
Software
Data model, interfaces between systems, and the screens the work actually happens on.
Hardware
CAD, tolerances, print orientation and a bill of materials that can be sourced twice.
Prototype
The cheapest honest version, in someone's hands, fast. A prototype that flatters the idea has failed at its only job.
Software
A working slice running on real data, not a clickable picture of one.
Hardware
A printed part on the bench in the same week, revised as many times as it takes.
Build
Turn the thing that worked once into a thing that works every time. This is where the tests, the tolerances and the boring rigour go in.
Software
Hardened, instrumented, access controlled, and covered by tests that would catch a regression.
Hardware
Repeatable print and assembly steps, firmware, and a check that says a unit passed.
Deploy and operate
Shipping is the start of the obligation, not the end of it. We stay on the system after it goes live, which is also how the next round of the Lab gets its evidence.
Software
Live, monitored, and maintained by the people who built it.
Hardware
Units in the field reporting to the same platform, updatable without a site visit.
The stages are fixed. The depth is not. A two week internal tool and a device that has to run unattended for a year get the same order of operations and very different amounts of stage four.
Where each track actually is
An R&D page is the easiest place on a website to overclaim. Here is the honest state of each track, using the same three labels we use internally.
Customer-facing AI assistants
Answering enquiries on a live platform, against a real catalog and real pricing.
In productionBack-office automation
Quotation, contract and invoice steps that used to be manual, running on live orders.
In production3D printed parts and fixtures
Enclosures, mounts and jigs designed and printed in-house to support our own builds.
In developmentRobotics
Service and assistant units: expressive interface, on-device behaviour, updatable brain.
In developmentEmbedded and IoT
Controllers and sensors reporting into the platform an operation already runs on.
In developmentEdge AI on device
Models running on the unit itself, so it keeps working when the connection does not.
ResearchIn production means it is running for real users today. In development means it is being built and is not a product yet. Research means we are still finding out whether it should be. If hardware is part of what you need, talk to us early and we will tell you plainly where we are.
Bringing the Lab a problem
The Lab takes on work that does not have an off-the-shelf answer. If a product already exists for what you need, we will tell you to buy it.
Applied AI builds
An assistant, agent or automation designed around your data and your rules, with the evaluation written first so you can see what it does before it faces a customer.
Hardware prototyping
From sketch to a printed, wired, working unit you can hold, then the path to making the same one repeatedly.
Process adoption
We run your team through the same five stages on one of your own projects, and leave the method behind in writing.
Feasibility work
A short, scoped answer to whether something is worth building at all, ending in a recommendation you can act on either way.
Joint development
Longer engagements where the Lab and your engineers build together, with ownership of the output agreed in writing at the start.
Second opinions
A review of a system or a device someone else built, focused on what will break and what it will cost to keep.
Working on something that does not exist yet?
Tell us what you are trying to make. We will tell you what stage it is really at and what the next one costs.
Talk to the Lab