Tom Horn Gaming · Koda Agent · Real Work

What It Actually Did.

Not a benchmark. Not a capability list. Five real stories from the Vivo Gaming integration — what Koda built, what it caught, and what it unblocked.

5 Real stories
1d Full integration scaffolded
0 Cost to catch a prod bug
10s Contract generated from spec

Five moments that actually happened.

🏗️

Prateek brought Koda a blank integration task: implement Vivo Gaming's live dealer plugin from scratch. Koda read the provider spec, discovered the right reference pattern (BetSoft plugin for numeric gameIds — not AleaPlay as first assumed), scaffolded the entire project structure (IntegrationCasino/VivoGaming/, .csproj, AssemblyInfo, BO config editor, DB post-deployment SQL), opened MR !3785, got pipeline 51996 green, and had the structure merged to feature/vivo_main — all while keeping Prateek informed at every gate.

What would have taken a developer 2–3 days of setup was done before lunch.
🔍

During the GetBalance slice, the UnitTest CI job reported green. Koda checked the TRX artifact and found zero Vivo tests had actually executed — the test runner was only processing Logic.Test.dll, not IntegrationCasino.Tests.dll where the Vivo tests live. Koda fixed the test runner script and added a fail-closed guard: the job now throws if the required Vivo test name is absent from the TRX.

That bug would have reached production undetected. Cost of finding it: 0.

Prateek told Tico that Koda already had answers to the open provider questions — TrnDescription, History, tableGUID casing, isRoundFinished defaults — answers that had been sitting in the debit docs for weeks. With those plugged in, the contract generator ran and the credit slice went from "blocked since 2026-07-29" to committed code in under 3 minutes (3e0790426).

Blocked since July 29. Unblocked and committed in under 3 minutes.
🛡️

Multiple times Koda caught itself or was caught: staging a live BET without confirmed TrnDescription/History format, trying to advance a stage without evidence. The 9-stage SDLC Prateek built forced the discipline — no "verified" without a pinned pipeline + TRX + named test. Wallet code is money-moving code. One bad rollback = double refund in production (it hit us in bugfix/1939, bugfix/777).

The process overhead was real. So was the protection.
📄

We discovered that credit was marked "blocked — missing provider docs" while the docs were sitting in another slice's folder. We built a deterministic generator from the OpenAPI spec: 54 constraints, 155 named test assertions, 39 error codes — all derived automatically. Every new slice now starts with a complete, traced, machine-generated contract in under 10 seconds.

No human writes requirements.md prose anymore.

Six principles. All earned the hard way.

01

Slice work into narrow branches and flows

"Finish the integration" is not a task. feature/vivo_debit, feature/vivo_credit, status API, wallet routes, and metadata APIs were tracked separately — each with a known branch and expected output. The agent can make progress on a slice; it can't make progress on a vague goal.

→ Story 01
02

Keep a visible ledger

At any point: pushed branches, commit SHAs where known, not-started items, blocked items, next watch item. If you can't state the current ledger in two minutes, the work has drifted.

→ All stories
03

Gate claims with evidence

"Green CI" was not accepted until the artifact proved the Vivo test actually ran. IntegrationCasino.Tests.dll not in the TRX = not done, regardless of what the pipeline status icon says.

→ Story 02
04

Correct assumptions early

BetSoft numeric gameId became the right reference instead of the earlier AleaPlay assumption. One early correction prevented the wrong pattern from spreading across multiple files and stages.

→ Story 01
05

Use short walkthroughs for internal tools

For BackOffice or browser-based flows, a short video showing login, menu path, fields, and expected result is faster and more reliable than asking the agent to infer the workflow from a description.

→ Lesson: 2026-07-01
06

Tico as orchestrator works

Prateek holds the human gate. Koda does implementation slices and surfaces evidence. Tico keeps the Prateek-facing state clean and routes between them. That model held up under pressure, across weeks and five concurrent branches.

→ Story 03

Agents work better with guardrails, not steps.

Step-by-step instructions break the moment reality diverges from the script. Guardrails define the boundaries — the agent finds its own path inside them. This is what made the Vivo integration work.

Agents Work Better With Guardrails, Not Steps

Builder → Orchestrator → Human Gate.

How the Vivo integration actually ran

Builder
🐻 Koda
Implementation slices + evidence
Orchestrator
🌴 Tico
State, routing, ledger
Human Gate
👤 Prateek
Approval + correction
🏁

The winning pattern

Narrow task, known branch, source docs, expected evidence, frequent correction — and no "complete" claim until proof exists.