(Special thanks to Bren DeNunzio, Sindhuja Vutukuri, and Kyle Boss for their help with this piece.)
In the last few years, AI has begun to reshape how teams build and ship products, moving from experimentation to a practical part of everyday engineering work. But turning an agent into a dependable teammate at TinderⓇ’s scale requires more than access to a model: it needs secure protocols, trusted connections to internal tools, reliable deployment, observability, cost controls, and clear human approval gates.
Even more considerations rose as adoption grew. Teams began creating their own harnesses and rebuilding the same foundations independently. Similar skills and agents were being created to solve overlapping problems, with no shared way to discover, govern, operate, or improve them. Rather than asking every team to solve those platform challenges from scratch, we created Agentis ("Agent" + "Genesis"): Tinder's end-to-end platform for building, deploying, running, and observing AI agents at production scale. It gives every team a paved road—runtime, models, tools, workflows, and governance—so an engineer can go from an idea to a production agent in hours, not weeks.
Today, Agentis runs a fleet of roughly 200 agents: code reviewers that compile suggestions before they make them on real AppleⓇ hardware, an Reliability engineering agent that root-causes alerts from a Slack ping, coverage agents that raise iOS test coverage overnight, full SDLC workflows with human approval gates built in, and workflows that are able to automatically remove unused code, properly modularize code, and fix regressions throughout the codebase. Nearly every Tinder developer works with agents daily. (Real numbers below.)
Running agents against a consumer mobile app shaped the platform's defining rule: an agent earns autonomy by proving its work. Human approval gates are first-class steps in our workflows. Suggestions ship with evidence—a green build, a passing test, a video of the engaged feature. Our review agents are themselves evaluated by other agents that compare their feedback with subsequent human reviews.
This post is an overview of the platform. Several components deserve their own deep dives, and we'll call those out as we go.
Why we built a platform
And Tinder's constraints raised the stakes of leaving every team to solve those alone. Our product is a consumer mobile app: the most valuable work our agents can do lives in iOS and Android build toolchains that serverless agent runtimes don't run, either due to fundamental incompatibilities or sheer resource constraints. That work sits behind internal systems that demand real access control. And it ships at a scale where a bad automated change reaches millions of people. (More on how we cracked the mobile problem in the runtime section below.)
These unique constraints also made it difficult for us to find a match with any off the shelf managed agents solution. While plenty of products exist in the Agent platform category, none came equipped with the things we truly needed: agentic mobile development tooling, harness-agnosticism, open-source model support, full self-hosting.
The answer was building our own platform with a strong opinion: a paved road, not a walled garden. Standard paths are frictionless; escape hatches exist, but you keep the observability and governance either way. Two other principles shaped everything downstream: security is not optional—agents get scoped credentials, audit trails, and the same controls in dev as in prod—and observe everything by default: tracing, cost attribution, and audit trails come free with the standard path, not as opt-in work.
The architecture at a glance
A request enters through either a trigger or a workflow and is authenticated and routed by the Agentis Gateway. An agent then executes on a Tindroid runtime, using Model Context Protocol (MCP) tools and skills and calling models through the LLM Gateway. Everything—spans, tokens, and cost—is captured in observability by default.
A label, a mention, a schedule
Before the component tour, here's what the platform feels like to use: three ways work reaches agents, no console in sight.
An engineer adds a label to a task ticket. Within a minute, the mapped agent, here Merlin, our engineering agent, picks it up, reads the ticket and the linked thread, and posts a plan to a team chat thread. The engineer replies and approves; Merlin writes the change in an isolated worktree, runs the checks, and opens a draft PR. Total interaction: one label, one word.
An alert fires in an on-call channel. The engineer pings Dexter, our SRE agent that lives in alert channels; a chat integration passes the alert to Dexter, and Dexter runs its investigation across metrics and logs, returning a root-cause triage in the thread within minutes, all while the human is still reading the dashboard.
And some work needs no trigger at all: coverage agents run on a nightly schedule, and teams wake up to a capped batch of draft PRs raising test coverage on that day's slice of the codebase. Tech debt agents trigger daily and only notify engineers when they have fixed the issues and have mergeable PRs ready for review.
A label, a mention, a schedule: different agents, different teams, one platform underneath handling identity, routing, execution, and cost.
Every layer below exists to make those handoffs safe, observable, and repeatable across 200+ agents. Let's walk through them.
LLM Gateway: governed access to every model
The LLM Gateway is our model abstraction layer—a single API connecting agents to frontier model providers and cloud AI platforms, with authentication, retries, fallback, and cost tracking built in. It provides a standard path for model access: serverless agents can call their runtime’s native model service directly for a fast path, while workloads that need multiple providers, budget enforcement, or cross-provider fallback go through the gateway.
The interesting part isn't the proxying. It's the governance:
- Tiered token budgets per team key (exploration tier vs. production tier), with soft caps that alert and hard cuts that prevent runaway costs.
- Cost attribution per team, per model, per day, which feeds budget-increase requests that are themselves reviewed through an Agentis workflow (the platform approves its own budgets on its own workflow engine).
- Smart routing. We built an offline A/B harness to answer one question: can we route queries to cheaper models without sacrificing quality? Benchmarking six routing policies, our adaptive router hit 82.4% of top-model quality at 70% of the cost, a 35% savings. It's now exposed as an open-smart-router model alias that our coding-agent setup tooling points developers at, we will have a separate post about smart routing.
Tindroid: the agent runtime
Tindroid is Tinder's agent runtime, and its pitch to internal developers is simple: your agent is a folder. Drop in the files you need—model, prompt, MCP configs, skills—then push, merge, done.
With Tindroid, we aim to give developers the right balance between agent configurability and platform support. Developers can choose their preferred agent harness, from SDK-based frameworks to command-line coding tools, connect to their choice of model provider, use a custom container image, or implement the entire agent loop themselves. Around that customizable runtime, Tindroid provides shared platform capabilities, including hosting, observability, event-based triggers, and CI/CD checks.
Serverless agents run on a managed serverless agent runtime; product-centric agents that need secure access to internal systems and have predictable traffic run on our internal Kubernetes runtime. Both receive agent discovery, session management, agent memory, sandbox testing, and observability from the platform. Scaffolding takes one command in your coding agent, for example, /create-tindroid a code review agent that reviews pull requests using source control and issue tracking MCP servers. The scaffolding skills follow the vendor-neutral Agent Skills specification, making them portable across compatible coding agents.
The mobile problem
Agent runtime only supports Linux microVMs, but Tinder ships iOS and Android apps. An agent that suggests an iOS code change it can't compile erodes trust in the entire platform. Our constraints are significant and challenged our entire mentality of building code: the runtime has ~21 GB of ephemeral storage (a full clone of our iOS monorepo doesn't fit; we cannot even start Bazel on these agents with our sparse clone; there is not enough memory to complete analysis), and containers are stateless. We needed to rethink our entire build to accomplish this feat.
The answer for us was using remote execution as the agent's hands: Agent runtime acts as the brain, delegating iOS builds to an elastic pool of Darwin executors via Remote Build Execution (the agent works from a sparse, blobless clone and ships its edits as a diff) and delegating end-to-end UI verification to a fleet of simulators, where elements are targeted in natural language ("the Like button at the bottom of the card") rather than brittle accessibility IDs. Android builds routes through a CI/CD connector. The result: our iOS review agents compile their suggested fixes on real Darwin hardware and only post suggestions that build green. Our build is now an easy to use and centralized API that all agents can use, enabling any of our Agentis agents to build, test, run and deploy iOS code effortlessly.
How requests move: gateway, triggers, and kill switches
Two thinner layers make the fleet usable and governable.
Agentis Triggers is how work arrives. Hundreds of meaningful events happen across an enterprise every day. We built an extensible platform to capture those events and translate them into agent invocations. It handles intake from team messaging, source control, issue tracking, incident management and generic webhooks, along with user-configured schedules. The label, mention, and schedule from the vignette above all land here and get dispatched to their mapped agent or workflow.
Agentis Gateway is the authentication and routing layer those requests flow through: a single front door for both internally deployed MCP servers and proxied external ones, and a dispatcher that abstracts agent invocation so callers never care whether the target runs on Serverless agent runtime or internal Kubernetes. One governance detail we've come to rely on: per-tool kill switches. Every MCP tool carries a runtime feature flag with a fail-closed override, so we can disable a single misbehaving tool in production without a deploy.
Skills Hub: reusable expertise
Skills—structured, versioned instruction packages a coding agent loads on demand—turned out to be the fastest-growing artifact on the platform. Skills can live in any internal repository; registering the repo gets them indexed by the hub and made discoverable to both platform agents and developers, who install them into their own coding agents. Roughly 600+ skills are indexed across our registered repositories and growing fast: build-and-test recipes, review checklists, deployment runbooks, and device-automation drivers, to name just a few.
AgentisFlow: durable multi-agent workflows
Single agents handle tasks; real processes need orchestration. AgentisFlow compiles a workflow definition into a DAG and executes it on a durable workflow engine with per-step retries, crash recovery, and replay safety. Workflows range from a PM’s weekly report assembled from team conversations and internal documentation to a full SDLC pipeline with human approvals.
Four primitives compose everything, and each one is a YAML file, not code:
The design tenets keep it honest:
- Dumb engine, smart agent. The engine schedules, tracks, and records; it never composes an agent's reasoning.
- Humans are first-class steps. A gate is an ordinary DAG node with a closed outcome vocabulary, and a rejection is a gate that worked and said no, not a failure.
- Artifacts pass by reference, never by payload, keeping workflow state small and durable.
- Definitions are data. Adding a legal-review step to a process is a pull request, not a deployment.
Our flagship sdlc-standard workflow runs product spec and UI design capture in parallel, converges into a technical design, passes human design, security, and legal approval gates, fans out implementation across only the platforms named in the build plan, hands off to a QA child workflow, and pauses at a ship gate.
Context: what agents know
At runtime, agents gather context through MCP tools for internal documentation, code search, team messaging, and source control, alongside a commercial platform for enterprise-wide search. That platform replaced our internally built search stack once maintenance costs outweighed the benefits of control. The lesson we'd pass on: buy the search, own the tools. Tool schemas and access control are where we add the most value; crawling and ranking are better handled by a dedicated search platform.
AgentisHub: the single pane of glass
AgentisHub is the control plane: one place to build, configure, discover, deploy, observe, and test every agentic component—agents, MCP servers, skills, and workflows. It's also where authentication integrations live, including on-behalf-of token propagation so an agent acting for an engineer carries that engineer's permissions into downstream systems rather than a god-mode service account. Agentis MCP will let the developers interact with Agentis to build and manage agents from coding agents.
The fleet: what 200+ agents actually do
The fleet clusters into developer experience, code review, coverage, bug fixing, SRE, and SDLC agents. A few that show the range:
- Domain-scoped review agents: CODEOWNERS-scoped reviewers that complement (not replace) general review bots with domain knowledge, and build-verify every fix they suggest.
- Review retro agents: Agents that evaluate our review agents’ outputs against the PR discussion that follows and propose improvements for human review and approval. This feedback loop helps engineers refine review quality with less manual analysis.
- Merlin: ticket in, reviewed plan, draft PR out, and it keeps following up on review comments and CI until the PR is green.
- Coverage agents: Undercover Agent runs nightly, bucketing our iOS libraries by day and opening capped batches of coverage-raising draft PRs; a sibling agent reads a ticket, checks out the code, writes unit tests to an 80%+ coverage bar, and opens a PR.
- Release Guardian: an autonomous iOS release-ramp watchdog that detects regressions, diagnoses the cause, pages the on-call, and (opt-in) opens draft-PR fixes, compiled on real Darwin hardware before they're proposed.
- Dexter, our SRE agent (from the vignette): hands it a link to an alert message in an on-call chat channel and it runs a two-phase root-cause analysis. Phase one is deterministic, no LLM loop: it enriches the alert with panel metrics, runbook and module insights, a change timeline, and ranked prior hypotheses. Phase two is a planner agent that never touches investigative tools itself. It only dispatches six specialist subagents (infrastructure, metrics, logs, code, incident history, docs) and synthesizes their findings into a report in the alert thread.
- Tech debt: Agents that automatically re-modularize our legacy code to match current standards and improve build times. Fix legacy regressions or migrate code to more modern patterns. Removing unused code automatically.
- Babysitting: Agents that are able to automatically fix and triage issues on PRs.
- TreeFlow: A SDLC agent fleet that is able to ideate, design, review, build and ultimately ship.
- Maintenance: Agent workflow that can observe other workflow agents and propose fixes in PRs and raise issues via Slack to their owners
- App exploration: Agents that are able to automatically explore our app in various configurations using real backend services to find issues, discover connections between screens and teach agents how to navigate our app to any feature.
- Flaky test quarantine: Discovers and quarantines flaky tests automatically.
- Not everything needs a model: Some "agents" are deterministic, a PR-reminder bot with zero LLM calls. The platform's value (triggers, identity, observability) applies either way.
Impact
- Babysitter: 68% of all PRs it engaged were ultimately merged. Saving over 2,200 engineer hours per year. Unblocks other agents such as our Decomposition agent
- Decomposition: After establishing trust in our automated decomposition agent we were able to enable automatic merging for its PRs. This gave us a 28 times improvement in turnaround time while also allowing this agent to work autonomously 24/7 (71% of agentic decomposition PRs are made outside normal working hours). Proper modularization is now seen as a given thanks to this agent.
- Maintenance: Our maintenance agent fleet can enable a single engineer to oversee 20 or more agent fleets at a time, keeping these fleets healthy and communicating back potential issues to the owner.
- Remove unused code: Able to remove thousands of lines of unused code automatically with zero human assistance.
- Flaky test quarantine: No longer are we notified of flaky tests by our engineers, our agent can always find these tests first and prepare test disable PRs immediately.
- App exploration: We now have a birds eye view of our entire app at any time for a spectrum of user configurations. This map can be used by agents to reason about our app and discover how to validate their work. As this map grows our agents become more and more capable to triage, fix and prove their work.
- Our security review agents and Tindiff review agents are catching high impactful bugs before releasing to prod.
What's still hard
These are areas requiring our continued attention and investment:
- Cost. Even with budgets and attribution, aggregate spend grows with adoption. Smart routing bought us 30%; we're now exploring open-weight models for high-volume/low-complexity paths and making agents themselves more token-efficient (caching, distilled context, artifacts-by-reference).
- Security governance. On-behalf-of token propagation, scoped credentials, and audit trails exist, but permission management across 200+ agents and dozens of internal systems is an ongoing program, not a solved problem.
- Guardrails for builder-created agents. When anyone can create an agent, "which agent can access what" becomes the central question: per-agent cost governance, prompt-injection defense, and PII detection are active workstreams.
Earning the next gate
We opened with the platform's defining rule: an agent earns autonomy by proving its work, with human checkpoints and oversight appropriate to its demonstrated reliability and the risk of the task. That's also the roadmap. Every human gate in our workflows is a claim that an agent hasn't yet proven itself on that step, and every verification mechanism we build (build-green checks, retro grading, per-run cost analysis) is evidence that lets us remove one. The technical roadmap—long-term agent memory, a shared knowledge store, a prompt hub with A/B testing—serves that same question: which gate do we remove next, and what does an agent have to prove to earn it?
We'll cover the deep dives, including mobile build execution, agent evaluation loops, workflow orchestration, and routing economics, in follow-up posts. Stay tuned.
