About
A small studio that ships running systems.
Darko AI is an engineering studio, not an agency of account managers. The people who scope your system are the people who build it. We keep the client list short on purpose, because an autonomous system that nobody watches for the first month is a liability.
Why the work looks the way it does
Most of what breaks in production AI is not the model. It is the plumbing around it: a provider returning an empty completion that gets read as an answer, a retry loop with no ceiling, a gate that logs a failure and ships anyway, a credential that lives in one person's laptop. We have hit all of those and the architecture we use now is shaped by them.
So the boring parts get built first: state that survives a restart, limits that a model cannot argue its way past, gates that fail closed, and logs a human can actually read.
Safety is enforced in hardware
Exposure timers, current limits, thermal cut-offs and watchdogs live in silicon and firmware. A computer, a model or a prompt is never the last line of defence.
The instrument describes itself
Every device publishes its modules, sensors, limits, calibration and supported commands as a machine-readable schema. Software discovers hardware; it does not assume it.
Model-agnostic by design
Hardware and protocol engines run without any AI model. Claude, OpenAI, local models and plain scripts all talk to the same documented API, USB, BLE and MCP surfaces.
Measured, not assumed
Optical output, temperature and timing are measured with calibrated sensors and logged with synchronized timestamps. Nominal specifications are inputs, not evidence.
What we turn down
Volume plays that kill accounts
Mass DMs, scripted bulk actions, engagement pods. They work for a few weeks and then the account is gone and the domain is burnt.
Agents that have never run live
A green build is not a shipped system. If it has not run unattended against the real API, it is not finished and we will not call it finished.
Black boxes
Nothing we build should be impossible to take over. If a handover would leave you stranded, the architecture was wrong.
Numbers we cannot show the log for
We publish operating parameters, not results we cannot evidence. That is why this site has no testimonial wall.
How an engagement runs
- 01 30 minutes
Scope
One call. We map the function you want an agent to own, the systems it has to touch, and the decision it is allowed to make on its own. If an agent is the wrong answer we say so on that call.
- 02 3–5 days
Blueprint
A written architecture: the action loop, the data it reads and writes, the model chain with its measured fallbacks, the limits, and the failure behaviour. Fixed price attached before a line is written.
- 03 2–4 weeks
Build
Built against the real APIs from day one. No mock data, no staging fiction. You get access to the run logs while it is being built, not after.
- 04 Ongoing or handover
Run
It goes live under supervision, then under monitoring. Managed operation, or a full handover with the runbook and the repo. Your call.
Contracting entity
Ganbaru Kodo Limited
trading as Darko AI
Registered office
No. 5, 17/F STRAND 5050 BONHAM STRAND, SHEUNG WANHONG KONG