Available · Fractional · Q3 2026

Multi-tenant infrastructure for AI agent products.

If you've launched an AI agent product and now need to make it work for many customers instead of one, I build the multi-tenant infrastructure underneath. Fractional or project-based.

Kevin Hill Asunción · UTC−3 kevin@omoios.dev
How it works

The layer underneath your agent product.

Most teams ship single-tenant agent demos quickly. The gap between that demo and a multi-customer product is where I work.

// architecture · simplified
Multi-tenant agent platform architecture Three stacked layers. The top layer shows multiple customer tenants, each with its own GitHub App and isolation boundary. The middle layer is the orchestration layer (isolation, routing, sandboxing, and observability), labelled "what I build." The bottom layer is the runtime infrastructure: Cloudflare Durable Objects, Modal sandboxes, OpenCode runtime, and GitHub Apps. Animated flow lines connect the layers; pulse rings emphasize the orchestration nodes. CUSTOMERS Tenant A github app · iso Tenant B github app · iso Tenant C github app · iso Tenant N … ORCHESTRATION LAYER · WHAT I BUILD isolation routing sandboxing observability RUNTIME · CF + MODAL + OPENCODE durable objects modal sandboxes opencode runtime github apps
What you get

What changes after we work together.

The technical work has a purpose: removing the engineering friction between your tenth customer and your hundredth. Here's what that looks like in practice.

Before

  • One customer works. The second one breaks something subtle in production.
  • Every new tenant takes a senior engineer half a day to onboard.
  • Your GitHub App is wired for your dev account, not your customers'.
  • Sandbox isolation is "we hope nothing escapes."
  • You're three months from needing to hire a senior platform engineer FT.

After

  • New tenants come online without engineering involvement.
  • Each customer's code, secrets, and runtime stay strictly isolated.
  • GitHub App installation is a customer-driven flow you don't think about.
  • The orchestration layer has real visibility per tenant.
  • You're 3–6 months ahead of the infra hire, or never need it.
~6mo

Deferred the senior platform-engineer FT hire, saving the equivalent of $90k+ in fully-loaded cost while still shipping.

Typical target · estimate
0 eng hrs

To onboard a new tenant. Goes from a half-day engineering task to a customer-driven flow with no human in the loop.

Target outcome · post-engagement
1–2 wks

To working multi-tenant isolation. First engagements deliver a deployed boundary, not a slideware architecture document.

First-engagement scope
Selected work

What I've built, and what it proves.

Three projects, each with its own arc. I lead with the one most relevant to what you'd hire me for.

Active project · 2026

Multi-tenant background agents

Fork of a popular open-source background-agents repo · in progress

The problem

The most popular open-source background-agents codebase explicitly punts on multi-tenant deployment. The README lists the gaps: per-tenant GitHub Apps, access validation at session creation, tenant isolation in the data model. Real product teams need exactly those pieces.

What I'm building

A fork that closes the gaps. Per-tenant GitHub App installation flows. Access validation enforced at session creation. Tenant-isolated data model. Sandbox orchestration on Cloudflare Durable Objects + Modal + OpenCode runtime.

Where it stands

Architecture decided, foundation built, milestones tracked publicly on GitHub. Demo and architecture writeup coming in the next few weeks.

What this means for you

I'm solving the exact problem this site sells, in public. Available to apply this work to your product as a contract engagement, usually starting with the highest-friction piece in your stack.

GitHub (coming soon) Writeup (coming soon)
Shipped · open-source · 2024–2025

OmoiOS

Autonomous agent platform · Apache 2.0 · 60★ on GitHub

The idea

A self-hostable platform where you write a feature spec, agents execute it overnight in cloud sandboxes, and you wake up to a PR. Built before "background agents" was a named category.

What I built

Multi-agent DAG executor on Daytona sandboxes. Spec-to-PR pipeline. Self-hostable so teams could run it on their own infrastructure. Designed for parallel agent execution with proper isolation between tasks.

What happened

60 stars on GitHub, working demo, real users. I couldn't find product-market fit as a managed service and stopped pursuing it commercially. The orchestration patterns I developed are the foundation of the multi-tenant work I do now.

What this proves

I've shipped autonomous agent infrastructure end-to-end before "background agents" became a named category. I know what the right abstractions look like, and what they cost when you build them in a vacuum. I bring that to your product.

Post-mortem (coming soon) Repo → Project site →
Research collaboration · 2025

Weather forecasting on NVIDIA Earth-2

Regional ML infrastructure for Paraguay · with collaborator Fran

The problem

Paraguay's meteorological infrastructure has real gaps. High-resolution regional weather modeling needs serious GPU orchestration and data pipelines most teams can't stand up.

What we built

Data pipelines for regional meteorological inputs. Inference orchestration on GPU infrastructure. NVIDIA Earth-2 framework integration for high-resolution forecasting.

What this proves

I work with serious ML infrastructure beyond LLM agents. The same orchestration patterns transfer across domains, and I can ship with research collaborators on time-bounded work.

Findings → Project plan →
How this works

What an engagement looks like.

No long discovery process, no slideware. Most engagements move from first call to working infrastructure inside two weeks.

A 30-minute call

You describe what you've shipped, what's breaking, and where the multi-tenant gap lives. I tell you whether I think I can help, and what the first week would actually look like. If we're not a fit, you'll know on this call.

No-cost · usually within 48 hrs
A focused first engagement

Usually 1–2 weeks. An architecture review plus a build of your highest-friction piece, often the per-tenant GitHub App flow or the session isolation boundary. Fixed scope, fixed price. You walk away with working infrastructure either way.

Typical scope · 1–2 weeks
Continue, or don't

If the first engagement lands, we continue on retainer or project basis until you've got the multi-tenant layer you need. If it doesn't, you've still walked away with working infrastructure and a clear architecture review.

Optional · retainer or project-based
About
Kevin Hill, looking at the camera with glasses pushed up on his forehead.

Engineer · Paraguay.

I'm Kevin Hill, an American engineer who moved to South America. I'm now based in Asunción, Paraguay. I've spent the last several years building agent infrastructure, multi-tenant SaaS, and data systems, most recently on Cloudflare Workers, Modal, OpenCode, and Daytona. I've also supported and run production mobile apps in Flutter for both iOS and Android. I co-run a workforce development company as a separate venture; this site is for my independent engineering work.

I work US-business-hours-friendly from UTC−3. Engagements are fractional or project-based, not full-time. Invoiced through Wise or Stripe.

What I don't do

  • Pick LLMs or models for you
  • Write prompts
  • Take full-time roles
  • Generic "AI strategy" consulting
TypeScriptPythonRustFlutterCloudflare WorkersDurable ObjectsModalOpenCodeDaytonaSQLitePostgres

Building an AI agent product? Let's talk about the layer underneath.

Tell me what you've shipped, where the multi-tenant gap is, and what you'd want different in 30 days. I'll reply within 48 hours with whether I think I can help.

kevin@omoios.dev →
GitHub X LinkedIn