Introducing Agent Control: OnePay's Internal CLI for AI Builders

Share

This continues the story we've told in The OnePay Platform Story, Inside OnePay's AI Journey, Scaling Engineering, Tokki, and Arnab. This time it's about the connective tissue beneath an engineer's local experience: agentctl, OnePay's internal CLI, built to help us turn customer needs into products and features faster.

From Customer Need to Shipped Product

Product velocity at OnePay starts with a customer need, usually a simpler way to save, invest, spend, borrow, or manage money, and it moves fast from there. Along the way, the requirements might live in Jira, the design in Figma, the decisions in Slack, the customer insight in our Data Platform, and the relevant product behavior scattered across several parts of the codebase.

This is the work behind OnePay's shipping pace. Our Shipping page is the receipt: IRAs, family and teen banking, recurring crypto purchases, iOS widgets, My Garage, launched at a rate most would call reckless.

Before an engineer writes a line of code, they're often authenticating into several systems and pulling together repos across workspaces. None of that is hard on its own — it's tax. agentctl removes it: one federated sign-in across OnePay's systems, and workspaces that gather the repos you need automatically.

Now picture that same engineer starting a coding agent and just describing the outcome. The agent gathers context, finds the relevant code, implements it, runs the tests, and preps the change for review. The engineer still owns every real decision, they just stop being the adapter cable stitching six tools together.

The command that makes that possible is agentctl.

What Is agentctl?

Agent Control, or agentctl, is OnePay's internal command-line interface for AI-native engineering. It's one supported entry point to configure and launch coding agents, reach approved models, connect OnePay tools, install shared workflows, navigate our codebase, and coordinate more complex work. The shortest version looks like this:

agentctl configure
agentctl plugins install
agentctl run $HARNESS

Those three lines hide a fair amount of platform work. agentctl establishes delegated sign-in, discovers available models, applies managed configuration, registers integrations, and checks that the local environment is healthy, all before you type a command that actually does anything. It can configure Claude Code, OpenCode, or Codex today while keeping the OnePay platform underneath them consistent.

That distinction matters. The coding agent is the experience an engineer chooses. The model is the intelligence it uses. The gateway, identity, integrations, and policies are shared platform capabilities. Separate those layers, and we can adopt better models and new agent experiences without asking every engineer to rebuild their setup from scratch.

Think of agentctl as a universal remote for engineering at OnePay: one small interface that brings a much larger system within reach.

One Front Door, More Choice

AI development tools are improving at an extraordinary pace. The best model for understanding a large codebase may not be the best one for a quick edit. A model that leads today may be surpassed next month. An agent that fits one engineer's workflow may not fit another's. We didn't want to turn those choices into fragmentation.

agentctl gives engineers access to multiple coding agents and model families through a single stable entry point. Authentication is delegated through company sign-in, model endpoints are discovered rather than manually copied, and managed settings sit alongside personal preferences instead of replacing them. One diagnostics command checks the whole path when something's wrong.

For engineers, that means less setup and more choice. For OnePay, it means we can improve shared routing, observability, and reliability once, while still applying the right safety controls to each supported agent. It's the same principle behind our mobile platform evolution: unify the foundation without limiting what teams build on top of it.

One Gateway, One Control Plane

Behind agentctl is the OnePay AI Gateway, the shared control plane between our coding agents and a fast-changing landscape of models and providers. Routing supported agents through one gateway gives us a single source of truth for how AI coding tools are used across the company, with centralized rate limits, PII guardrails, and cost attribution by user. It also means improvements to model routing, reliability, and observability can benefit every supported coding agent without requiring engineers to reconfigure their local tools.That control point becomes more important as agents grow more capable and autonomous. Instead of governing a dozen separate doors into our AI stack, we can focus on one. The gateway is a key part of our AI strategy: it gives us the freedom to adopt new models, providers, and coding agents while keeping governance, visibility, and control consistent across them.

Plugins Turn Knowledge Into Capability

Connecting an AI agent to a model is useful. Teaching it how OnePay actually works is where the experience becomes differentiated.

We built the OnePay Plugins marketplace as a curated library of integrations and reusable workflows: more than two dozen internal and vetted third-party plugins spanning developer operations, incident response, security, data engineering, performance testing, user research, business automation, and the everyday systems where our work happens. A plugin can package a few different kinds of capability:

  • Tools connect an agent to a system through the Model Context Protocol (MCP).

  • Skills encode a repeatable workflow: the sequence of steps, the expected evidence, the output format.

  • Specialized agents bring a focused role and instructions to a larger task.

That's a real shift. Traditional documentation tells a person what to do. A well-designed skill gives both the person and the agent a repeatable path for actually doing it. Our shared skills already help engineers investigate where a change is deployed, work through merge-request feedback, triage an incident across operational systems, plan a performance test, or figure out the minimum AWS access a task actually needs. These aren't generic prompts. They carry OnePay's tools, conventions, safeguards, and definition of a good result.

The marketplace also changes who gets to improve the platform. A data engineer can publish a workflow for diagnosing pipelines. Security can encode the correct access path. An SRE can turn the lessons from an incident into a runbook available in every future coding session. Platform teams provide the distribution mechanism, but the expertise can come from anywhere in the company. When a workflow improves, everyone using it benefits immediately; institutional knowledge stops living in one person's terminal history and starts compounding across the whole engineering org.

Arnab's Reach, From the Terminal

In Introducing Arnab, we wrote that "the depth in each integration is the product." A Slack connection that can only send a message isn't enough. A production integration has to help an agent search, read, understand, and act, while still respecting the user's own identity and permissions. agentctl brings that same integration platform into the local engineering workflow.

Through a lightweight MCP router, a coding agent discovers the service it needs and loads only the tools required for the task. That's what lets engineers work with things like Slack, Jira, Datadog, GitLab, Notion, Figma, PagerDuty, Zoom, n8n, and OnePay's Data Platform without loading hundreds of tool definitions into every single session.

This is a direct line between Arnab's broad company context and an engineer's local one. Arnab might help someone chase down an operational question from Slack or the web; the engineer can pick up that exact thread from their terminal, with the codebase and dev environment already in front of them. Both experiences draw from the same integrations instead of rebuilding a separate connector for every agent and interface. The result is more than convenience. It lets context move with the work.

In a product workflow, the coding agent can find the Jira requirements, inspect the Figma design, read the decisions in Slack, navigate the relevant code, and use trusted data to understand the customer experience, already sitting in the environment where the feature gets built and tested. The line between understanding, building, and shipping gets a lot thinner.

This also extends the work we described in Building OnePay's Data Platform. Governed access to trusted data isn't just useful to analysts and applications anymore. It's useful to agents working on an employee's behalf too, under exactly the same permissions that always applied.

The Codebase Is Part of the Platform

OnePay is a multi-product company with a large, multi-repository codebase. Even experienced engineers rarely hold the whole system in their heads. Finding the right repository, understanding how services connect, and creating a safe place to make a change can take longer than the change itself.

agentctl workspace treats that environment as another platform capability. It can discover repositories, optionally index a searchable local workspace, and create isolated worktrees for changes while keeping the base checkout clean, the same workflow available to a person at the command line and to an agent through MCP, with the same underlying checks either way.

This is the local counterpart to Tokki. Tokki makes OnePay's codebase conversational through a browser and Slack, backed by isolated cloud sandboxes. agentctl meets engineers where they already work: theirterminal. Different surfaces, same goal: make the knowledge in our codebase easier to reach and safer to change.

Trust Has to Be Part of the Interface

An internal CLI that can connect AI agents to company systems must make the safe path the easy path.

We designed agentctl around a few principles:

  1. Use delegated identity for gateway access. Model access uses company sign-in and short-lived credentials, and static gateway keys are not written into agent configuration. Integrations retain their service-specific authentication.

  2. Preserve the user's authority. User-authorized integrations operate with the employee's access, not a universal agent identity. Connecting an agent does not bypass the service's permissions.

  3. Separate managed and personal configuration. OnePay-owned settings are applied through managed overlays, while engineers retain their own themes, preferences, and project configuration.

  4. Limit capability deliberately. Read-only modes expose only tools the upstream service identifies as read-only. In OpenCode's autonomous mode, designated sensitive operations are denied, and an unavailable or inconclusive safety decision blocks the call.

  5. Observe the system without collecting the work. Operational telemetry helps us understand reliability, latency, and adoption, while intentionally excluding prompts, tool inputs, tool results, credentials, and other arbitrary user content from the integration router's metrics.

None of this got bolted on after some AI prototype proved useful. It's part of the product from day one. In financial technology, speed only matters when it preserves customer trust.

Why This Compounds

The visible benefit of agentctl is time saved during setup or investigation. The larger benefit is platform leverage: a new model becomes available to everyone at once instead of a new set of instructions to learn; an integration built for Arnab is reachable from the terminal; an incident lesson becomes a skill; a safety control upgrades multiple agents simultaneously; a new engineer inherits a working environment and OnePay's encoded practices on day one. Solve a hard problem once, expose it through a simple interface, and the value multiplies across teams.

That's also how we think about becoming AI-native: not more time spent on AI tools, but the company's context, capabilities, and standards embedded wherever work already happens, so engineers spend more time on the products and reliability customers actually experience.

agentctl started as a way to point coding agents at a shared model platform. It's becoming the internal CLI for how OnePay engineers work with AI, one place for agents, models, plugins, integrations, and code. Arnab, Tokki, our engineering agents, and agentctl each make different work easier, but their value compounds because the identity, integrations, knowledge, and intelligence underneath are shared.

We're building the tools that help us build OnePay. If you want to help create the infrastructure, agents, and developer experience behind an AI-native financial platform, explore our open roles at onepay.com/careers.