MY WORK

I'm Eranga, a hands-on lead engineer with 14+ years across agentic AI, sports trading and gaming with crypto, and payments. Most recently Applied AI Lead at Chaos Theory, designing Cloudbet's agentic platform. The harness engineering, the model pipelines, and the backend systems they stand on.

A note before the tour. Most of this work lives in private organisation GitHub and GitLab repositories, so the code is not visible.

LinkedIn
01 Pulse Agentic social betting system · LangGraph fleet on GCP 2024–2026 02 Eliza OS runtime First-generation agent harness · 4,000+ users on real money 2024–2026 03 Sports trading Realtime odds distribution, risk-checked bet placement 2020–2026 04 Gaming platform Provider aggregation, wallet sessions, AI-first game ops 2020–2026 05 Wallet & payments Ledger-centric crypto rails · 26+ assets, chain watchers 2023–2025 06 Unamy Agentic conversational commerce for small businesses 2024–2025

Case 01 · Cloudbet

Pulse, an agentic social betting system

Applied AI Lead · architecture, harness engineering, model platform

Pulse is a live timeline where AI personas analyse markets, place play-fund bets and post about them, sport-specialist agents consult a shared news analyst, real players tail and copy the calls, and VIP concierge agents serve high-value customers privately. It started as one monolithic elizaOS agent and was re-architected into a scoped LangGraph fleet on Google Cloud. One loop (start → agent → tool → END) reused everywhere, with the trust model enforced in infrastructure rather than prompts.

The non-negotiables were backend decisions. Privilege separation. Only the internal Bet Placement agent holds placeBetOnBehalfOf and checkStakeLimits in its bindTools() array, persona, analyst and VIP agents call it as a tool and can never touch the Betting Engine directly. Human confirmation. Every player-funded bet pauses on LangGraph's interrupt(), checkpointed in Postgres, so a confirmation survives a crash, a deploy, or a VIP who replies four hours later. Load shape. A World Cup final doesn't melt the engine because Cloud Tasks rate-limits dispatch at 50/s with a circuit breaker in Redis shared across the fleet, and every placement carries an idempotency key derived from the thread and tool call ids.

Pulse feed in production: a whale's 13-leg correct-score parlay narrated by an agent
Exhibit 1a. The feed in production. A narrative agent posts a whale's 13-leg correct-score parlay seconds after the slip lands, live scores attached to every leg.
Bots tab: Battle of the Bots tennis leaderboard posted by Cloudbet Pulse, with community chat tailing a 12-leg parlay
Exhibit 1b. The Bots tab. Persona strategies (Old is Gold, Astrology Girl, Bit Bot…) competing on live ROI while the chat rail shares and tails a 12-leg multi.

Platform architecture, matched to traffic shape

Fig. 1. Compute matched to traffic shape. GKE for the always-on persona fleet, Cloud Run for request-shaped player replies, Cloud Functions for thin webhook ingestion, Pub/Sub to decouple settlement bursts from the workers that process them.

Agents posting Battle of the Bots updates while players share and tail bets in chat
Exhibit 1c. Agents posting on their own clocks. Cloudbet Pulse narrates the bot league while the community chat shares slips beside it.
Agent profile card: Tile Master with win rate, record, best streak and betting-style gauge
Exhibit 1d. Every agent has a public track record. Win rate, record, best streak, average stake and a safe-to-bold style gauge. Reputation is the product surface of the evaluator pipeline.
NBA analyst agent chatting with a player: analysis with model edge, staged bet card, confirm and decline buttons, placed receipt
Exhibit 1e. A specialist analyst agent in a player conversation. The model argues the edge with numbers from its tools, stages the slip, and the player confirms before a cent moves, interrupt() rendered as UI.

Inside one agent, the harness owns the run

Fig. 2. Harness engineering. The model is a stateless, rented reasoning step inside a loop the platform owns. State, budgets, validation, identity and safety all live in code, a prompt rule is a suggestion, a code gate is a wall.

Model router, pay for judgement only where a mistake costs money

Fig. 3. The routing economics. Fine-tuned 1–3B open-weight models handle the narrow high-volume steps (classification, scanning, routing, compaction) for latency, cost and data control. Frontier models are reserved for open-ended reasoning where a mistake is expensive.

The model factory, fine-tuning and evaluation as one gated pipeline

Fig. 4. The agentic evaluation workflow. Probabilistic components get the same discipline as code. Versioned, tested in CI against a golden dataset, shipped through shadow and canary, and monitored for drift, with the feedback loop closing from incidents back into the eval suite.

Worked example, calling a sports outcome straight from a tweet

Fig. 4b. The news fine-tunes in one flow. Evals make it shippable. A frozen golden set of 12k labelled tweets (including sarcasm, fan accounts and ambiguous "questionable" cases) scores per-field precision/recall, and the certainty ladder is calibrated against human labels, a tweet the classifier gets wrong becomes next release's golden case.

Pulse leaderboards: sharpest bettors and top earners by ROI and profit
Exhibit 1f. Leaderboards make reputation legible. ROI, profit and records for humans and bots on the same tables.
Parlay of the Week competition page with prize pool and live chat
Exhibit 1g. Parlay of the Week. A $1,000 prize pool on top of the feed's native behaviour, settled from the same bet-event stream.
Pulse feed on mobile
Exhibit 1h. Pulse on mobile, where tailing lives.

What it changed

  • Monolith → scoped fleet. Tool explosion, privilege bleed and untraceable bets engineered out structurally.
  • Zero unconfirmed real-money bets. The interrupt() gate is architecture, not policy.
  • Cost tiered by blast radius. Cheap models brag, strong models handle money, small fine-tunes absorb the volume.
  • Full auditability. Every bet decision is one trace. Context, tools, model version, confirmation.
LangGraphLangChainPythonFastAPIGKECloud RunGoogle Pub/SubCloud TasksNeon PostgrespgvectorRedisLangSmithHugging Face HubHugging Face PEFTQLoRAvLLMPresidioTypeScriptNext.jsSSETelegram APIMixpanel

Case 02 · Cloudbet × elizaOS

The Eliza OS runtime, the first-generation agent harness

Applied AI Lead · led the agentic transformation

Before the LangGraph fleet, this is where the agentic programme started. Turning an app-based sports trading product into one you can delegate to, built on elizaOS, the open-source TypeScript agent framework, and scaled to 4,000+ users engaging with agents betting real money under hard guardrails. It began as a hackathon prototype that took 1st place out of 30+ teams and became the production programme.

The runtime's contract is strict. Providers assemble context, markets, prices, bankroll, open positions, fresh each cycle. Actions are the only effects an agent can produce. Build a slip, place a bet within caps, publish a post. Evaluators score every cycle after the fact, bankroll discipline, strategy drift, and write to long-term memory so each agent's public track record stays honest. Open-weight models served from the Hugging Face Hub do the reasoning. Nothing reaches the trading APIs except through the same limits, risk checks and audit trail a human account gets. Running it at scale also exposed the monolith's ceiling, one flat action list, 30–50 tool schemas per call, no privilege boundary between analysis and execution, and those lessons became the design brief for the Pulse fleet above.

Sportsbook home with Parlay of the Week leaderboard and live in-play rail
Exhibit 2a. The surface agents operate in. Live markets, community parlays and leaderboards, all fed by the same bet-event stream the agents consume.
Whale watch widget tracking a live two-leg parlay with chance to land
Exhibit 2b. Agents and whales share one observability surface. Live positions, win rates, and a model-estimated chance to land.

The runtime loop

Fig. 5. Agents are powerful because they're constrained. The guardrail layer, not the model, is the design.

What it changed

  • 4,000+ users actively engaging with agents in production.
  • App-based → agentic. The product became something you delegate to, not just operate.
  • 1st place, Chaos Theory AI Hackathon. The prototype that seeded the programme.
  • The migration brief. Its production limits defined the LangGraph fleet's architecture.
  • AI-driven DevOps. An agent workflow now manages and ships the frontend app portfolio.
elizaOSHugging Face HubNodePythonPostgresRedisGoogle Pub/SubRAGMCPLangSmith evalsTypeScriptNext.jsSSEVercel

Case 03 · Cloudbet

Sports trading, realtime odds at wallet speed

Senior Fullstack Engineer → Tech Lead → Applied AI Lead · 2020–2026

Cloudbet trades thousands of live markets around the clock. I initiated the rewrite of the legacy main app and co-led it to delivery on a NestJS microservices stack on GKE, then led the realtime trading apps hands-on, integrating sports trading providers and keeping every open betslip honest against a feed that re-prices in milliseconds.

The backend is a classic read/write split under pressure. The read path, odds, flows from provider feeds through the pricing engine into Google Pub/Sub topics and out over websocket and SSE fan-out, with per-connection bounded buffers that coalesce to latest state so one slow client never backs up a hot stream. The write path, bet placement, is strict. The slip is re-priced server-side at submit, risk and max-stake limits come live from the risk engine, and placement is an idempotent transaction so a double-tap or a network retry can never double-bet. An auth + BFF layer gives each client one fast contract and hides the fan-out. Vercel adoption across the frontend catalog let a small team ship a large portfolio of apps with no dedicated DevOps.

Champions League event page with full-time result, Asian handicap and total goals markets
Exhibit 3a. An event page. Market groups stream re-prices over websockets. Community parlays sit beside the trading view.
UEFA Champions League listing with odds grid and Pulse rail
Exhibit 3b. League view with the Pulse rail alongside. The same odds cache serves both, so the feed and the trading view can never disagree.
Betslip with a single moneyline selection
Exhibit 3c. The betslip. Max-per-bet limits come live from the risk engine. Suspended markets block placement in real time.
Betslip in parlay mode with five legs and a 50 dollar stake
Exhibit 3d. Parlay mode, five legs staged at a $50 stake. Odds are a live feed, not a page. Every leg re-prices in the slip.

Architecture, read path fast, write path strict

Fig. 6. Reads are cached, replicated and coalesced. Writes are re-priced, risk-checked and idempotent. Every arrow carries a timeout, a retry policy and a metric.

What it changed

  • Legacy to microservices. Initiated the main-app rewrite and co-led it to delivery.
  • Auth + BFF delivery avoided the cost of a dedicated in-house auth squad.
  • Vercel platform. A large frontend catalog shipped and monitored by a small team.
  • Friction intelligence. A player-friction dashboard priced every drop-off step in dollars.
NestJSNodeGoogle Pub/SubgRPCRedisPostgresGKEPythonFastAPIGraphQLTypeScriptNext.jsReactWebSocketsSSEVercel
Sportsbook on mobile with NFL odds and parlay cards
Exhibit 3e. The same BFF contract serves mobile. Parity is architectural, not manual.

Case 04 · Cloudbet

Gaming, thousands of titles behind one session contract

Tech Lead → Applied AI Lead · realtime gaming vertical

The gaming vertical aggregates studios like Hacksaw, Pragmatic Play and BGaming plus live-dealer floors alongside Cloudbet Originals. In-house provably-fair games. I led the realtime gaming apps hands-on. The personalised lobby, the game-launch session pipeline, and the live win feeds, and drove the move that mattered most operationally. game and studio ops became AI-first workflows, cutting ~70% of the operational workload.

The hard part of an aggregator is the contract surface. Every provider launch is a short-lived signed session token carrying wallet binding, geo and compliance rules. Every spin settles through the same debit/credit API against the central ledger, so a provider can never hold a balance of its own. Win events stream back through Google Pub/Sub into the lobby's live feeds and into the analytics pipeline that prices launch failures and provider reliability in dollars. The AI-first ops layer sits on top. Agents that release titles, tune categories and assemble tournaments against the catalog service, human-approved, fully audited.

Lobby rows: Cloudbet Originals and BGaming hits
Exhibit 4a. The lobby in production. Cloudbet Originals (Mines, Pump, Limbo, Dice, Plinko…) above aggregated studio rows.
A BGaming slot running inside the casino shell with live balance
Exhibit 4b. Game launch. The provider's RGS runs inside the shell with a wallet-bound session, demo/real switch and the live bet feed underneath.

Architecture, the aggregation boundary

Fig. 7. One wallet session follows the player from lobby to any provider's game and back. The ledger is the only place money exists.

What it changed

  • ~70% less ops workload after game and studio workflows went AI-first.
  • Personalised lobby, "For you" rows from play history, not manual curation.
  • Provider reliability priced. Launch-failure telemetry in dollar terms drove contract conversations.
NestJSNodeGoogle Pub/SubPostgresRedisGKEPythonFastAPIProvider RGS APIsBigQueryNext.jsReactSSEMixpanelVercel
Casino lobby with For you tab, filters and live win ticker
Exhibit 4c. The "For you" lobby. Filters, volatility and theme facets served from the catalog service. The live win ticker streams from the Pub/Sub win-event topic over SSE.

Case 05 · Cloudbet

Wallet & payments, a ledger with doors

Tech Lead · with the Payments team

A betting platform is a wallet with opinions. Together with the Payments team I overhauled the crypto wallet and payments flow. 26+ currencies, instant on-chain deposits, wallet and exchange connections, and a single double-entry ledger that sports, gaming and promotions all settle against, no internal transfers, no provider-held balances.

Money paths are where classic backend discipline earns its keep. Deposits. Per-chain watchers follow confirmations, credit the ledger in a transaction that writes the balance change and an outbox event together, and survive reorgs by re-verifying before finality. Withdrawals. A request passes velocity rules and compliance checks inline, queues for review only when a rule trips, then goes to the signing service and is tracked to broadcast, every step idempotent, every state transition evented, with rejected attempts first-class citizens in the history. The player sees two honest doors, transfer crypto, or connect a wallet, and a transactions view that mirrors the chain's own states.

Add funds modal: transfer crypto instantly or connect a wallet or exchange
Exhibit 5a. The two doors. Transfer any of 26+ coins, or connect MetaMask / WalletConnect / an exchange in about two minutes.
USDT deposit screen with network selector, QR code and deposit address
Exhibit 5b. Deposit flow in production. Token + network selection (USDT on Ethereum here), a derived address, and chain watchers crediting after confirmations.
Active balance popover with USD balance, deposit, withdraw and history actions, and per-asset balances
Exhibit 5c. The balance surface. One active balance, per-asset sub-balances, deposit / withdraw / history one tap away.
Withdraw modal showing per-asset balances and instant daily limit
Exhibit 5d. Withdrawals. Up to $2,200/day instantly with risk checks inline. Playthrough state shown per asset, limits enforced server-side.
Transactions history with confirmed deposits and rejected withdrawals across XLM, USDT and ZEC
Exhibit 5e. On-chain history as the player sees it. Confirmed deposits, rejected withdrawals, per-asset amounts, the ledger's event log, rendered.

Architecture, both money paths

Fig. 8. The ledger is the product. Everything else is a door into it. Deposits reconcile from the chain in. Withdrawals are risk-gated, signed and tracked out, both paths evented through the outbox.

What it changed

  • One ledger. Sports, gaming and promos settle against the same balance.
  • Deposit-to-bet in under a minute on fast chains.
  • Deposit friction measured in dollars. Every drop-off step priced on the friction dashboard.
  • No double-credits, no lost events. Idempotent watchers + transactional outbox.
NestJSNodePythonFastAPIPostgresGoogle Pub/SubRedisGKEChain RPCsgRPCWalletConnectNext.jsReact

Case 06 · Founder build

Unamy, agentic commerce for the smallest teams

Founder & engineer · unamy.ai

Unamy is a bespoke agentic conversational-commerce system for small and medium businesses. The boutique, the salon, the home baker whose entire storefront is a chat thread. Their catalog and every customer conversation live in one place, and an AI agent works beside them at exactly the level of trust they choose.

It's the same harness discipline as the trading floor, scaled to a two-person shop. The trust dial maps to tool scopes. In draft mode the agent holds no send-capable tools at all. In semi-auto it answers within a whitelisted intent set and hands over the rest. In full-auto it runs the conversation but orders, bookings and payments still pass a confirmation gate under the owner's rules. Each business onboards with its own catalog, voice and boundaries, context assembled per-tenant, memory scoped per-tenant, never shared.

Exhibit 6a. The inbox. Every channel in one list, AI-answered threads marked, a new customer arriving live.
Exhibit 6b. AI mode (the private purple lane). The owner asks for a reply from the catalog. The agent checks stock and drafts the product card, the customer can't see any of it until the owner taps send.
Exhibit 6c. Hand to AI. A personal trainer types @AI, picks full auto, and the agent reschedules the session end-to-end, labelled as AI the whole way.

The three screens above are the product's own animated scenes, running live. They show the whole trust dial in order. The shared inbox where AI-handled threads sit beside human ones. The private AI lane where the agent reads the catalog and stock ("Lena wants the blue mug. You have 12 in stock."), drafts the reply with the product card attached, and waits for the owner's tap. And the full-auto handoff, where the owner picks how the agent should handle it, the chat switches to an "AI has this chat" bar, and every message the agent sends is labelled AI to the customer.

How it's built

Fig. 9. The trust dial is a tool-scope dial. Autonomy is granted by what the agent can call, not what it's asked to do.

What it does for the shop

  • One inbox for every channel. With the AI working the queue alongside the team.
  • Catalog-grounded replies. The agent answers with real items, prices and stock, never from imagination.
  • Autonomy per conversation. Draft, semi-auto or full-auto, switchable mid-thread with @AI.
  • Honest by design. Customers always see which replies came from the AI.
NodeHugging Face HubSupabasePostgresRedisTypeScriptNext.jsSSEiOS · Android · Web