The Holy Trinity of AI DevOps: Atlassian, GitHub and AWS from One Coding Agent
Follow one coding agent across Atlassian, GitHub, AWS, and Dynatrace to see how AI can safely carry context from ticket to code, runtime, and telemetry.
Most coding-agent demos start inside a repository, but that is only one part of how I actually work. The reason for a change might live in Jira, the implementation is in GitHub, and AWS tells me what is really running. If I want an agent to help across that workflow, giving it access to the repository is not enough.
For this setup I am using Kiro CLI, although Kiro is not really the subject. I am connecting the agent to the tools I already use: Atlassian for the work, GitHub for the code, AWS for the runtime, and Dynatrace afterwards to verify the result. The interesting part is that most of this does not require a custom agent platform. MCP, existing CLIs and Agent Skills already give us most of the pieces.
Atlassian: giving the agent the reason behind the work
I start in Atlassian because the repository rarely contains the complete reason for a change. A Jira work item can have the original request, comments added later, status changes and links to other work. Before the agent starts looking for code, I want it to understand what somebody actually asked us to change.
For this I am primarily using Atlassian CLI, or ACLI, rather than treating everything as an MCP problem. ACLI gives Jira a proper command-line interface, which makes it a natural fit for a terminal-based coding agent. It can retrieve work items, search using JQL, list comments and return JSON that the agent can consume without scraping a web page. Atlassian also supports OAuth through the browser, so the first setup can be as simple as:
1
2
acli jira auth login --web
acli jira auth statusOnce authenticated, retrieving the work itself is explicit:
1
acli jira workitem view PROJ-123I can also ask for only the fields that matter:
1
2
3
acli jira workitem view PROJ-123 \
--fields summary,description,comment \
--jsonThat
--json option is particularly useful for an agent. I would rather give Kiro structured data than terminal output designed for me to read. ACLI also supports JQL searches when the task is less specific:1
2
3
4
acli jira workitem search \
--jql "project = PROJ AND status = 'In Progress'" \
--fields "key,summary,assignee,status" \
--jsonAnd if I want the discussion around a specific work item separately:
1
2
3
acli jira workitem comment list \
--key PROJ-123 \
--jsonThose commands give the agent a deterministic way to inspect Jira using exactly the same pattern I use elsewhere in this setup.
acli for Atlassian, gh for GitHub, aws for AWS and later dtctl for Dynatrace. The agent does not need a bespoke integration every time a mature CLI already exposes the information cleanly.Rovo MCP still has a place, but I see it as complementary rather than the main interface. ACLI is excellent when I know which work item, project or JQL query I want. Rovo MCP becomes more interesting when the question is broader, such as finding relevant information across Jira and Confluence when I do not already know where that information lives. Its search and fetch tools can retrieve context across Atlassian products using natural-language requests.
That gives me two ways into the same system. For predictable operations I use ACLI. For broader discovery across Atlassian context, the agent can use Rovo MCP.
A prompt at this stage could be:
Read PROJ-123, including its description and comments. Work out what behaviour is expected and identify anything that changes how we should approach the implementation. Do not modify the work item.
I would still keep the first pass read-only. ACLI can edit work items, create comments, transition them and perform other write operations, but understanding the task does not require any of that.
The flow for this part of the article is therefore slightly different from the original version:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ATLASSIAN
Jira
│
├──────────────┐
▼ ▼
ACLI Rovo MCP
│ │
deterministic discovery
operations + context
│ │
└──────┬───────┘
▼
Coding agent
│
▼
Understand the workBy the time I leave Atlassian, the agent should understand why the change exists and have the relevant Jira context in the same session. Now it can take that information into GitHub and work out where the change belongs.
GitHub: connecting intent to the code
GitHub is where the workflow moves from understanding the request to understanding the implementation.
GitHub has an official MCP Server that exposes repositories, code, issues, pull requests and Actions workflows to compatible agents. It also has
gh, which already provides a stable command-line interface for many of the operations I use every day. Official GitHub MCP Server a MCP is useful when the agent is exploring relationships between repositories, issues, commits and pull requests. The CLI is often better when the operation is already explicit and I want something predictable.
For example:
1
2
3
4
gh auth status
gh repo view
gh pr list --state open
gh run list --limit 5The important difference is that the agent arrives at GitHub with the Atlassian context still available. Instead of vaguely searching the repository, it can use the ticket requirements to decide which files, commits and pull requests matter.
A prompt at this stage could be:
Using the requirements from PROJ-123, find the code responsible for this behaviour. Check recent commits and open pull requests affecting the same area. Explain the change you would make before editing anything.
Once the proposed change makes sense, the agent can modify the local checkout, run the project's existing tests and show the diff.
1
2
git diff
git statusI do not need a special AI testing abstraction here. If the project already uses
pytest, npm test, go test or terraform validate, the agent should use the same commands as everybody else.After reviewing the change, GitHub becomes another checkpoint:
1
2
gh pr create --fill
gh pr checksThe PR description can now contain more than a summary of the diff. The agent has the original requirement from Atlassian, so it can explain how the implementation maps back to that requirement.
At this point it understands why the change exists and how the repository implements it.
It still does not know whether the repository describes what is actually running.
AWS: checking the system that actually exists
GitHub tells me what we intended to deploy. AWS tells me what survived contact with reality.
A deployment might have failed. A Lambda function could have a different configuration from the repository. Somebody might have changed a resource manually. Any debugging workflow that stops at Git is working from an assumption.
AWS now provides the Agent Toolkit for AWS, which combines the managed AWS MCP Server with AWS Agent Skills. If you have AWS CLI 2.35.0 or later, the CLI can detect supported coding agents, install the default skills and configure the MCP connection:
1
aws configure agent-toolkitThe current setup supports coding agents including Kiro, and AWS also documents direct installation paths when you do not want to use the wizard. Agent Toolkit for AWS setup guide
I like the separation between the components. The MCP Server gives the agent authenticated AWS capabilities. Skills give it procedural AWS knowledge. The AWS CLI remains available when a normal command is the clearest way to get an answer.
Before doing anything interesting, I still want this:
1
aws sts get-caller-identityOnce an agent can inspect several AWS accounts or profiles, knowing which identity it is using is part of the task, not housekeeping.
I would also start with read-only access. AWS supports both OAuth and SigV4 for the MCP Server, but SigV4 is particularly useful for terminal agents because it supports multiple AWS profiles and can run in a mode that hides write-capable tools from the agent completely. AWS MCP Server authentication guide
The prompt can now combine what the agent learned from the first two systems:
Inspect the AWS resources related to PROJ-123. Compare the deployed configuration with what exists in the repository and identify differences that could explain the behaviour described in the ticket. Do not modify AWS resources.
The calls depend on the workload. A Lambda problem might lead towards function configuration and CloudWatch logs. An ECS issue could require task definitions and deployments. An infrastructure problem might involve CloudFormation or resources created from Terraform.
That flexibility is useful. I want the agent to choose the AWS evidence based on the problem rather than follow a hardcoded script.
This is where the three parts of the trinity finally connect. Atlassian tells the agent what should happen. GitHub tells it how we think that behaviour is implemented. AWS tells it what is actually running.
That is enough to investigate a problem across most of the software delivery path without manually moving information between systems.
There is still one missing piece.
Dynatrace: checking whether the change worked
I include Dynatrace because I do not want deployment status to become the definition of success.
If the ticket was about latency, I want to see latency. If it was about errors, I want error data. A technically successful deployment can still make the service worse.
dtctl is useful here because Dynatrace designed the CLI for both people and coding agents. It supports structured agent output, a machine-readable command catalogue, and an installable Agent Skill compatible with Kiro and other Agent Skills clients. Dynatrace dtctl documentation The skill can be installed globally:
1
dtctl skills install --globalBefore querying telemetry, the agent can discover what the environment actually contains:
1
dtctl inventoryFor commands that need machine-readable output,
--agent returns structured JSON rather than terminal formatting:1
dtctl query "fetch logs | limit 20" --agentThe final interaction can now refer back to the same requirement that started the workflow:
The change associated with PROJ-123 has been deployed. Find the telemetry that best represents the behaviour described in the ticket and compare the periods before and after deployment. Do not modify Dynatrace configuration.
That is why I see Dynatrace as the verification layer rather than a fourth member of the trinity. Atlassian, GitHub and AWS take the agent from intent to runtime. Observability tells us whether any of that work produced the result we expected.
I would keep Dynatrace read-only as well. Investigating telemetry and changing production because of telemetry are very different levels of authority.
One agent, many ways to work
The workflow in this article is one example: Atlassian provides the work context, GitHub the code, AWS the infrastructure, and Dynatrace the runtime evidence. What matters more is that these integrations are available whenever the agent needs them, not only when I follow that exact sequence.
I can ask the same agent to create or update Jira work items, review a pull request, trigger a GitHub Actions workflow, inspect AWS infrastructure, investigate unexpected cloud costs, or use Dynatrace to understand what a service is doing. Sometimes those tasks connect together. Often they do not.
That is the real value for me: giving the AI agent access to the same engineering tools I already use, through CLI, MCP and Agent Skills, while keeping write operations behind clear permission boundaries.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article