Skip to content
Talk to an architect
Agents and automation

The agents we govern are the agents we build.

Custom development is the Forge apps, ScriptRunner automation, and integrations that close the gap between what Atlassian ships and what a specific estate needs. Atlas Bench builds them to run inside the platform, with the identity and change record the rest of the estate already uses.

Forge apps in production at scale, plus Rovo, Agents in Jira, and MCP work with Claude and Copilot, built by the same architects who design the permission model underneath them.

source build review deploy run scope check built inside the permission model, not beside it L1 L2 L3 L4

The problem

Most enterprise automation is built beside the platform rather than inside it. A script with its own credentials, a middleware account nobody owns, an integration user created for a project that ended. Each one works, and each one is a permission the platform cannot see.

That is manageable when the thing running is a nightly job. It stops being manageable when the thing running can decide what to do next.

What the work is

Solution design

Working sessions ending in an approved design covering work types, the data model, permissions, and the integration surface, signed off before build.

Forge application development

Applications built on Atlassian infrastructure, inside the permission model you already govern, rather than beside it with credentials of their own.

Agent and automation build

Rovo, Agents in Jira, and MCP-connected tooling, scoped to what the identity model actually permits them to reach.

Data and asset modeling

Schema design for the objects the automation acts on, with relationships modeled and migration of existing records planned rather than assumed.

Integration and synchronization

Scheduled synchronization with your systems of record, replacing scripts that run on somebody's machine.

Lifecycle, usage, and cost governance

Ownership, scope, review dates, audit trails, and stop conditions defined with the build rather than after it.

Testing, training, and handover

Structured acceptance testing, hands-on training on your own workflows, and documentation so your team can run and extend it.

How it runs

  1. Discovery and design

    2 weeks

    Confirming processes, fields, and reporting needs with the team who will use it, ending in a documented solution design approved before build.

  2. Build

    2 to 4 weeks

    Configuration and development in a sandbox against the approved design, with a tracked decision and open-item log.

  3. Testing and training

    2 weeks

    Sandbox acceptance testing with the team, then hands-on sessions using your workflows rather than generic demonstrations.

  4. Rollout and hypercare

    2 weeks

    Production rollout and a hypercare window before the system transitions to your team.

What you get

  • An approved solution design covering work types, workflows, fields, the data model, and permissions
  • The application or automation itself, running on Atlassian infrastructure inside your permission model
  • A data model with relationships modeled, plus migration and validation of existing records
  • Scheduled synchronization with your systems of record, replacing manual or scripted transfer
  • Lifecycle documentation for anything non-human: owner, scope, review date, and stop conditions
  • Reporting for the people who have to operate it day to day
  • Structured acceptance testing, defect triage, and remediation
  • Hands-on training on your own workflows, plus workflow and administration documentation
Start here

Four layers. One accountable system of work.

The layer everyone wants sits on the layer everyone ignores. Every engagement starts at one of these four, and whichever door you come through, the other three are still load bearing.

L4

Agents and Automation

Rovo, Agents in Jira, Forge, MCP with Claude and Copilot, agent lifecycle, usage and cost governance.

2 services

Atlassian Anthropic
L3

Governance and Change

Permission architecture, audit and compliance, ITSM and change control, change management, strategic reporting and budgets.

4 services

Atlassian Guard Jira Service Management Strategy Collection Jira Align
L2

Platform and Migration

Migration of every kind, tool consolidation, licensing, standardization, the system of work.

3 services

Atlassian Miro AWS Azure
L1

Identity and Access

Human and non-human identity, SSO, SCIM, least privilege, access reviews, Guard cleanup, Agent SSO readiness.

2 services

Atlassian Guard Okta

load-bearing, bottom to top

Proof

~3,000

Atlassian sites running the Forge apps our app studio, AppsDelivered, builds and maintains.

AppsDelivered listings on the Atlassian Marketplace, read 17 September 2026. Sum of the install and download counts the listings publish.

5M+

Monthly active users on Rovo, which makes agent capability table stakes and governance the thing that differentiates.

Atlassian Q2 FY26 shareholder letter.

World Class Software Development Finalist, 2024-2025

World Class Software Development Finalist, 2024-2025

Atlassian Partner Awards, 2024-2025

Questions we get

Why Forge rather than a connector?
Forge runs on Atlassian infrastructure, inside the permission model you already govern. A connector sitting outside the platform is one more thing with its own credentials and its own owner.
Do you maintain what you build?
If you want us to. Maintenance is where most custom work fails, so it is scoped as an explicit option rather than assumed either way.
Can you work on something another partner built?
Yes. That usually starts with a review, because the first question is whether the permission model underneath it is sound.
What about agents specifically?
Same discipline as any other identity. Who owns it, what it can reach, when it gets reviewed, and what it costs to run, defined with the build rather than bolted on.
How small is too small?
A single well-scoped workflow is a reasonable first engagement, and often a better one than a broad program. It creates the pattern and the internal proof for whatever follows.

Atlas Bench delivered a maintainable CI platform solution that transformed how we build, test, and release products. They identified roadblocks early and delivered on time. Highly recommend for any DevOps project.

Paul Mohan Das Paul Mohan Das Engineering Manager
featured guide

ScriptRunner scripts from Data Center rarely move to Cloud as they are, because Cloud has different APIs, time limits, and feature behavior. The better approach is to inventory every script, read the code, and decide whether each one becomes native Jira, Automation, a Forge app, a ScriptRunner Cloud rewrite, or nothing at all.

Read the guide

Recent resources

Find out what an agent would inherit.

Fixed scope. The assessment reads the three layers an agent lands on, identity, platform and governance, before anything is switched on. You get the findings, the ownership gaps, and the order to close them in.

Get an agent readiness assessment

By sending this you agree to our privacy policy.

Not ready? Talk to an architect