Trusting agents with code: how Brale is adopting agentic development

At Brale, we move money. When software that issues, custodies, and pays out stablecoins behaves incorrectly, the cost isn't a broken page. It can be a real financial loss.

So when I started building a way to bring AI coding agents into our engineering workflow, I didn't start by asking what agents can do. I asked what controls and data we would need to trust them.

The result is agentic-development-workflow, an open-source framework I wrote and that we're now adopting at Brale. Here's what it does, why I designed it the way I did, and how we're putting it to work.

What the framework does

The framework plugs AI coding agents into the issue-based lifecycle that teams already run on GitHub. Work moves from issue to deployment through the same steps a human contributor would follow:

1. 01 · Plan

   1. Issue
   2. Groom (optional)agent:groom
   3. Design (optional)agent:design

2. 02 · Build

   1. Implementagent:developer
   2. Continuous integration
   3. Reviewagent:review
   4. Respond

3. 03 · Ship

   1. Merge
   2. Deploy

Each step is triggered by a GitHub label or event. A person opens an issue and can ask a grooming agent to classify it and surface clarifying questions. For complex issues, the grooming agent adds a plan label, and a design agent then drafts an engineering design document and breaks the work into sub-issues. A person merges that design before any implementation begins.

When a person applies the agent:developer label, a developer agent implements the change on a fresh branch and opens a pull request. If the continuous integration checks fail, the agent is re-invoked to diagnose and fix it. A separate reviewer agent can review the PR, and the developer agent responds to feedback until the change is approved.

Then a human merges it. If a deployment fails, the agent opens a follow-up fix, and the cycle starts again.

The design philosophy

The framework grew out of how my own approach to coding agents changed over time. I've worked through four models, each handing agents more of the work:

The factory model fits how LLMs actually behave. The same agent given the same task can produce a different result on every run, so building software with agents becomes a process control problem. Where do you inspect? What do you test? Which steps should people own? Answering those questions means keeping every step of the process visible, rather than hiding it inside one agent managing its own subagents.

Agentic-development-workflow is my experiment in running that factory. Three ideas shaped how I designed it:

Agents are contributors, not magic. LLMs are trained on human writing, so giving agents the same roles and channels as human developers sets shared expectations. Each agent authenticates as its own GitHub App, so its commits, comments, and reviews are distinguishable from people's and from each other's. Agents work through issues, pull requests, and review comments, utilizing the same channels, audit trail, and tooling our engineers already use.

Least privilege, every time. Each agent action runs in an ephemeral container with a short-lived token scoped to only the permissions that action needs. The reviewer agent can comment on a pull request, but it can't push code. Only allowlisted users and agents can trigger workflows.

Humans gate the transitions that matter. Branch protection requires at least one human review, and agents can't approve their own work or push directly to main. People decide when work starts, whether a design is sound, and when code ships. Logs and session transcripts are captured for every run, so reviewers can see not just what an agent changed but how it got there.

How we use it at Brale

We're adopting the framework incrementally, starting where the work is well defined and the outcome is easy to verify.

Our first focus is routine maintenance: dependency upgrades that require code changes, and generating reports. This work is necessary, recurring, and time-consuming. It's also bounded. A good upgrade PR has a clear scope, and a reviewer can tell whether it stayed inside it.

Every agent-authored change still goes through human review, and reviewers check more than whether tests pass. They confirm the change is appropriate for the scope of the issue and follows the patterns our codebase already uses. An upgrade that quietly refactors an unrelated module or invents a new convention gets sent back.

Each run also gives us data: how often agent PRs are approved as written, where they need correction, and which kinds of tasks agents handle reliably. Agents take on more only as that record shows they can handle it.

Hard things, carefully

In building financial technology, "probably correct" isn't a standard. When inaccurate application behavior can carry substantial financial consequences, trust has to be earned and measured.

So we treat agentic processes the way we treat any system that touches money. We define the controls, collect the data, and expand scope only when the evidence supports it. Separate identities make every action attributable. Scoped, short-lived credentials limit what any single run can affect. Human review keeps judgment where it belongs. Captured transcripts make each decision auditable after the fact.

That reflects how Brale works in general: We succeed by doing hard things carefully. Agentic development is no exception.