Authorize your tools
The agents act as you: they need your Jira and GitHub accounts, once. Open each link, allow, come back and refresh. Links are single-use and valid about 10 minutes.
Agents that work as you.
AI agents on AWS Bedrock AgentCore with your own identity: every Jira comment, git commit and pull request carries your name, and an agent reaches only what you can. Two agents today: US to PR turns a ticket into a draft PR and heals its CI when it goes red (a fix commit as you, two attempts, then a hand-off comment), Review a PR reviews any pull request as you.
How it stays safe
Your identity, your rights
Tokens are vaulted per person under the agent's identity. Revoke any time from your profile; the agent asks again.
Guards between stages
Tests untouched, scope inside the spec, changes inside the diff, branch ai/* only. A guard failure stops the run and says why. Before the PR opens, the repository's own lint, type and build checks run on the change and what it broke is fixed inside the diff; the Checks table is in the PR body.
Everything traceable
Each run has a reference on the ticket, in Slack and in CloudWatch, with its cost. Humans hold the merge.
…
| Signed in via | Okta · Agentic Platform auth proxy |
|---|---|
| Session expires | … |
| Acts as | You: Jira comments, git commits and pull requests carry your identity; the agent can reach only what you can. |
| Runs recorded | … |
Authorizations
Once per tool. The agent stores a token under your name and acts as you; revoke any time in Atlassian (Connected apps) or GitHub (Authorized OAuth Apps).
How it works
In Slack: @Jira create ticket in a thread, then the ai-build label. Or from My tickets here. The agent plans and specs as you, you approve, it builds and opens a draft PR as you, a colleague merges.
Review a pull request
Paste the PR. In a few minutes the review is on it, posted by you, with inline findings.
Review every new PR of a repository
Name the repository once. Each PR opened or marked ready there is reviewed, signed by you. Or only the PRs wearing a label (Customize). Disable at any time.
Administrators
Budget caps
Cache
This deployment
The resources this page and the agent are wired to. If an apply from another checkout changes them, it shows here.
In one minute
Two agents work as you: US to PR turns a Jira ticket into a draft pull request, Review a PR reviews any pull request. Every comment, commit and review carries your name and reaches only what you can reach. You keep the two decisions that matter: you approve the spec, a colleague merges.
Getting started sign in, authorizations, the banner, stopping a runOpen Profile ›
Sign in with Okta
- What
- Opens the portal under your name.
- How
- The usual company login. The session lives in this browser tab; closing it signs you out.
- Use
- Click Sign in with Okta. You come back to the page you started from.
Authorize your tools Profile
- What
- Gives the agents the right to act in Jira and GitHub as you.
- How
- Two consents, each asked once: Atlassian (Jira and Confluence together) and GitHub. The tokens are kept in a vault under your name; nobody else can use them.
- Use
- Profile → Authorize on each row, or the Step 1 card on Home. Revoke any time: the next run asks again.
The status banner
- What
- One strip on top of every page with the latest run.
- How
- Blue and pulsing: running, with the current step. Amber: your ticket's spec is ready for approval. Red: failed or stopped, with the cause and what to change. Green: done, with the link to the result.
- Use
- Act from the banner (Approve spec, Re-run, Stop, See the runs). Closing it hides that run for good; the next run brings it back.
Stop a run
- What
- Ends a run that is still working.
- How
- The agent stops within a few seconds; nothing is delivered, and the run reads stopped by you. Only you, or an administrator, can stop your run.
- Use
- Stop on the banner, or on the run's card under In progress on Runs.
US to PR a Jira ticket becomes a draft pull requestOpen US to PR ›
Start a ticket
- What
- Runs part 1: the agent reads your ticket and the repository, then writes a plan and a spec as Jira comments, under your name.
- How
- If the ticket is unclear it first rewrites the description into a proper contract (the original stays underneath), or asks you two to four questions and stops. Nothing is written to the repository in part 1.
- Use
- Start next to the ticket. Same as adding the label
ai-buildin Jira, or from a Slack thread with@Jira create ticketthen the label.
Approve the spec
- What
- Your gate. Runs part 2: tests first, then the implementation, the repository's own checks, a self-review, and a draft pull request opened as you on a branch
ai/<ticket>. - How
- Four guards keep the agent inside the spec: it never touches its own tests afterwards, stays inside the listed files, and pushes only to its branch. A colleague reviews and merges; you cannot approve your own PR.
- Use
- Approve spec (or the amber banner), which moves the ticket to REFINED. Read the spec first: what it says is what gets built.
Re-run, Reset, transitions
- What
- Restart a part, put a ticket back to a clean state, or move it in the workflow.
- How
- Re-run part 1 plans again after you edited the description. Re-run part 2 resumes on the tests already pushed. Reset takes a delivered ticket back to the start. The Status column offers every Jira transition.
- Use
- The buttons on the ticket row, or Re-run on the red banner after a failure.
What a good ticket says
- What
- The ticket is the agent's only briefing.
- How
- Five things: the repository, the problem, the expected behavior, numbered acceptance criteria that can each become one test, and file pointers when you know them. One repository, about a day of work, nothing architectural or security-critical.
- Use
- Write it that way, or let part 1 rewrite it and check the result before approving.
Choose the model LLM
- What
- Which AI model runs each step, for your own runs.
- How
- Sensible defaults (a cheap model for the simple steps, a strong one for planning and coding). Your choice applies to your runs only, from here or from Jira.
- Use
- LLM on the US to PR page: pick a step, a company, a model, Save. Default puts the platform's choice back.
When a run stops
- What
- The red banner and the ticket comment say why, in plain words.
- How
- Authorization missing: authorize on your Profile, then Start again. Questions: answer them in the description, Start again. Guard: the message names the files and the edit to make in the spec or description, then Re-run. Weekly PR cap of the repository reached: wait, or ask the repository owner. Budget cap reached: ask an administrator.
- Use
- Read the message, fix the cause, Re-run.
Review a PR one pull request now, or every new one of a repositoryOpen Review a PR ›
Review one pull request
- What
- Posts a review on any pull request you can read, under your name, with comments on the exact lines.
- How
- Two passes: the agent lists what it found, then tries to disprove each point and keeps only what survives. Findings already posted by an earlier review are not repeated. Verdict ready or needs changes. It never edits the code and never runs the tests.
- Use
- Paste the PR link, Customize for the type of review (quick, standard, deep) and the checks (correctness, security, company rules, style), LLM for the model, then Review as me. Two to five minutes. Template, next to Customize, shapes what is posted: the summary on or off (off = only the inline comments, one per finding on its line), the verdict line, inline comments, list or table, emojis, grouping, footer, and Instructions: your own words on how the findings are written (a language, a tone, "suggest a fix for each finding"), with a preview; Changes in Customize, Template or LLM are saved as your defaults at once (a short Saved confirms) and apply to every review of yours. The findings themselves never change with the template. In every LLM picker, the ! mark after a model or a company tells its price per million tokens, what a typical run cost here, its strengths and weaknesses, context and engine.
Review every new PR of a repository
- What
- Every pull request opened (or marked ready) in that repository gets a review automatically, signed by you.
- How
- You need admin rights on the repository. The platform installs a webhook on it as you and remembers your settings (type, checks, model, weekly PR cap for US to PR). Under Customize, Only PRs with a label narrows it to the PRs wearing a label (
ai-reviewby default): the others are ignored at no cost, and labelling an open PR starts its review. The row says webhook ok once the first event arrives, not verified before (see the prerequisites on top). - Use
- Type
owner/repo, Customize, Enable as me. The switch disables without forgetting; Customize changes the settings; Remove forgets the rule.
Fix a finding Your reviews
- What
- Applies one review finding on the pull request branch, as you.
- How
- The agent changes only what that finding asks, inside the files of the PR, then commits, pushes and explains in a PR comment. CI and the human reviewer judge.
- Use
- On Your reviews, open a review's findings and click Fix next to one.
Measure acceptance and outcomes Your reviews
- What
- Tells whether the reviews were useful, and what became of the pipeline's pull requests.
- How
- Measure acceptance reads the review threads: a finding is accepted when its thread was resolved, its lines changed or someone gave it a thumbs up. Measure outcomes reads the pipeline's PRs: merged, closed, reverted, time to merge, cost per merged PR.
- Use
- The two buttons on Your reviews; the figures show as colored bubbles.
Scheduled jobs
- What
- Housekeeping on a clock. Four jobs, all off until someone switches them on.
- How
- Weekly rule harvest: turns recurring human review comments into proposed company rules (a draft PR to trim). Review eval: after each new release, checks the reviewer against known pull requests you list in the eval cases form. Weekly cleanup report: lists stale test tickets, old branches and drafts, deletes nothing. Weekly skill harvest (administrators): learns from failed runs and proposes edits to the agent's instructions. A job runs as the person who switched it on.
- Use
- The switch on each row, or Run now. Reports fold under the row.
Improve the rules
- What
- Drafts company rules from what reviewers keep saying on a repository.
- How
- Reads the human comments on recently merged PRs and writes the recurring ones in the rules format, as a draft PR on the platform's repository. Nothing applies until someone merges it.
- Use
- A repository, a period, Harvest rules.
Runs everything the agents did as you, and what it costOpen Runs ›
A run card
- What
- One card per run: a review, a ticket part, a fix, a job.
- How
- Status, the current or last step, the result link, what it cost and which models ran, a cache pill, and the run id which opens the detailed log. Review cards fold out their findings with a Fix button each.
- Use
- In progress shows what runs now; All runs keeps the history with search and filters (kind, status, period). Re-run or Review again on a finished card.
Budget
- What
- What the runs cost this month, per person, against the caps.
- How
- Three caps may exist: a cap per step, a monthly cap per person, and a threshold at which you get one Slack nudge. A run that hits a cap stops cleanly and says so. One ring per person, you first; red when at the cap.
- Use
- Read only. Administrators change the caps on the Admin page.
Admin what applies to everyone · administrators onlyOpen Admin ›
Budget caps
- What
- The cap per step, the monthly cap per person and the nudge threshold, for everyone.
- How
- Empty means the platform's default, 0 means no cap. They apply at the next step of every run.
- Use
- Type the amounts or pick a preset, Save caps.
Administrators
- What
- Who may change these settings, run the skill harvest and stop anyone's run.
- How
- Some are named by the platform's configuration and cannot be removed here; the others are added and removed on this page. The list can never be empty.
- Use
- Add an email, or the cross next to a name.
Cache
- What
- What the runs keep between them to start faster: the repository clone, the test environment, a short brief of the repository.
- How
- One row per repository with ages and sizes. The switch turns the cache off for everyone at once; Clear forgets one repository. A cache problem never fails a run.
- Use
- Leave it on. Clear a repository when its setup changed a lot.
Not an administrator?
- What
- You can open the page and read it.
- How
- The forms stay read-only and the platform refuses a change with a clear message.
- Use
- Ask one of the administrators listed on the page.
Profile and About your account · this deploymentOpen About ›
Profile
- What
- Your account, when the session expires, how many runs you have, your two authorizations.
- Use
- The avatar at the foot of the menu. Authorize or Revoke per tool.
About
- What
- What this deployment is wired to: the agent, the running version, the identity, the tables, the caps.
- Use
- The small link at the bottom right. Copy gives the details to paste in a support request.
Your reviews
Scheduled jobs
Improve the rules turn recurring human review comments into company rules
Read the review comments people left on a repository's recently merged PRs and draft the recurring ones as company rules. You get a draft PR on the agent's repository to trim and merge; nothing is applied until then.