Action needed: authorize Jira and GitHub so the agents can act as you. It takes a minute and is done once.
Step 1 · before anything else
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.
Already done on another device? Refresh to check.
Bedrock Streaming · Agentic Platform
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), Code Review 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).
Loading…
How it works
In Slack: @Jira create ticket in a thread, then the ai-build label. Or from US to PR here. The agent plans and specs as you, you approve, it builds and opens a draft PR as you, a colleague merges.
One pull request · now
Review a pull request
Paste the PR. In a few minutes the review is on it, posted by you, with inline findings.
2 to 5 minutes. You can leave the page: the run keeps going, the banner follows it, the result shows below and under Runs.
Every new pull request · always
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 (Which PRs). Disable at any time.
Repositories reviewed automatically
Administrators
Budget caps
Cache
Activity
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, Code Review 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.
Sign inOkta, the company login. Once per browser.
Authorize your toolsOn your Profile, allow Atlassian and GitHub once. The agents use your accounts, never a shared one.
Start somethingA ticket from US to PR, or a pull request from Code Review.
Follow itThe colored banner on top and the Runs page show every step, the result and the cost.
Getting started sign in, authorizations, the banner, feedback, 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. GitHub alone is enough for Code Review; US to PR needs both. The page you land on after a consent names the tool you just authorized and what it enables.
- 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.
Feedback
- What
- Where you tell the platform team that something broke or is missing.
- How
- One form, two kinds: Declare a bug or Ask for a new feature. The row lands on the matching Confluence page under your name, next to the FAQ. On Runs, Report on a failed run opens the form with its reference. Under the form, Your requests lists what you sent with the status the team set; Delete removes one of yours. Administrators see All requests and move the status (To-Do, In progress, Done, Fixed) from there; the Confluence pages are live docs, so the lozenge can also be clicked on the page.
- Use
- The rail entry Feedback, at the foot of the menu; pick the kind, an area, a title, a few lines, Send.
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
- It first works out what the repository needs (language, versions, how CI tests it), then, if the ticket is unclear, rewrites the description into a proper contract (the original stays underneath), answering its own questions from the repository, the parent and linked tickets and your project's history; it asks you something only when two readings would lead to different code. No
Repository:line? It picks the repository your team works on and says which one and why. Too big for one run? It cuts the ticket into sub-tasks (each with its own plan and spec) and lists them on the parent; approving the parent builds them all in order into one draft PR. 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. The list shows only the tickets you triggered (you are their requester: the agent acts as you). Any ticket, yours or a colleague's, is started from the Start a ticket field with its key, or by adding the label in Jira; it then appears in your list.
Approve the spec
- What
- Your gate. Runs part 2: the toolchain is installed (PHP, Node, Go, Java, any version the repository asks for), tests are written 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. The verification tests stay in the agent's working copy: the PR carries only what the ticket asked for. 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 builds again from the approved spec. 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 (or let the agent infer your team's), 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. Any language: the agent installs what the repository needs.
- 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 → Settings, LLM in the bar: pick a step, a company, a model (saved at once). Default puts the platform's choice back.
Any language, any tool
- What
- The agent is not limited to Python and Node: it installs the toolchain each repository needs, at the version the repository (or the ticket) asks for.
- How
- Before building, a cheap step reads the manifests, Dockerfiles, CI and README and decides languages, versions, the dependency install and the test command as CI runs it. PHP comes as a static build (any 8.x, 7.x), everything else through a version manager; installs are cached, so the second run is fast. A stage that meets "command not found" installs the tool and continues. Only what needs running services (a database container, Docker) is left to the repository's CI, and the ticket and the PR say so.
- Use
- Nothing to do. If a tool could not be installed, the "stage 02 (toolchain)" comment on the ticket says which one and why.
Talk to the agent
- What
- When a run waits for you (questions on the ticket, a failed or stopped part, a spec waiting at the gate), a text box appears under the banner, on the run card and on the ticket row.
- How
- Your text is posted as a comment on the ticket under your name, the channel the agent reads first, and the right part restarts at once: part 1 after questions or a remark on the spec, part 2 after a failure in part 2. No label to touch, no transition. The box disappears once the new run is recorded, and never shows on a delivered ticket or a finished review: nothing listens there.
- Use
- Type, Send. A line
Repository: owner/namein your reply is enough when the agent could not find the repository.
When a run stops
- What
- The red banner and the ticket comment say why it failed, where, and how to fix it as numbered steps.
- 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. No plan or spec comment on the ticket: part 1 never ran here, start it (remove
- Use
- Follow the steps in the order given, then Re-run.
pr-opened if present, add ai-build), approve the spec, part 2 follows. GitHub or Jira refused a call: re-authorize on your Profile.Code Review one pull request now, or every new one of a repositoryOpen Code Review ›
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: the settings show as colored rows, one open at a time, each saying what it is now. Type of review (quick, standard, deep), Checks (correctness, security, company rules, style), Model, Context (the repository's saved sources, or some for this review only), then Review. Two to five minutes. The Template row 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. The shape follows the Android chapter's reviewer: the summary is one line per finding (severity, file:line, title), and each inline comment shows the title with its Why?, the fix and a one-click suggestion collapsed underneath: your own words on how the findings are written (a language, a tone, "suggest a fix for each finding"), with a preview that reads like the posted review; changes in the rows 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). The row Which PRs, Only 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. The Agentic Platform GitHub App is installed on the covered organizations, so the webhook is created for you; on a repository elsewhere the rule is kept and the hook is added by hand. - Use
- Type
owner/repo, set the rows (the same as for one PR, plus Which PRs and PR cap per week), Enable. Your repositories open from Repositories reviewed automatically under Enable, five a page, with a search, an organization filter and All / Enabled / Disabled. The switch disables without forgetting (the person who enabled it, an admin of the repository or a portal administrator); the pencil opens that repository's settings in a popup (Save or Cancel); the trash forgets the rule.
PR templates for a repository
- What
- The commit messages, PR title and PR description of the US to PR runs on a repository.
- How
- Each of the three on its own, first one set wins: the ticket's PR templates section (
Commit:,PR title:, a code block for the description), then what the repository enforces (commit rulesets ofai/*, commitlint, a PR title check in its workflows, its PULL_REQUEST_TEMPLATE file; a rule is met by rewriting the message), then the templates its admins set here, then the default. The description is always filled by the agent from the run, short, with the verdict on top and the run details folded below. The progress line says which source each one came from. - Use
- On US to PR → Settings, PR templates in the bar, then the repository on the left (filter by organization, search by name, Customized for the ones with their own settings). Admins type a template in Commit, PR title or Description; it is saved a moment later. Placeholders:
{key}{summary}{type}{scope}{repo}, and{stage}for a commit. Empty = the default.
Context for a repository
- What
- Confluence pages and documents (architecture, ADRs, conventions) that the agents read before working on a repository, and cite when a decision rests on them. Each agent has its own list: US to PR reads what is set for US to PR, the reviews what is set for reviews; a source can be shared by both.
- How
- Without any setup they also read the repository's instruction files (
AGENTS.md,CLAUDE.md, Copilot and Cursor rules,CONTRIBUTING.md, and for a review those of the folders it touches), the README, and for a review the Jira ticket the PR names; the repository's admins switch each of these per agent under Always read. Everything is read as the person who runs the agent: a page that person cannot read is skipped, the run goes on. The plan and spec comments end with a Context line, the review footer counts the sources, the run card shows a context pill. - Use
- For US to PR: on US to PR → Settings, Context in the bar, then the repository on the left (filter by organization, search by name). For reviews: on Code Review, Review every new PR of a repository, type the repository, Context. Admins pick Confluence page (its URL, child pages for its children), This repository (
docs/,docs/adr/*.md) or Other repository (owner/repo/docs), then Add: it is read once at once so you see whether it is readable. also for reviews (or also for US to PR) shares a source with the other agent; Remove takes it out of this agent's list. In Review a pull request, Context shows the reviews' sources of the PR's repository; when it has none, add sources there for that review only (read as you, not saved).
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. The fix run shows under that review, and the button becomes its state: fixing…, ✓ fixed with the commit, nothing to change, or fix failed with Retry.
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.
Review as me, or as Agent
- What
- Who signs a review on GitHub: me, your own GitHub token and your name, or Agent, the platform's GitHub App agentic-platform[bot].
- How
- As Agent, the runtime mints a short-lived installation token of the App for that repository; clone, review and comments run with it. The App must be installed on the repository's organization (it is on most of ours). Your name stays on the run, the budget and the Activity card; only the review's author changes. Enabling automatic reviews still needs your own admin rights on the repository: the webhook is created with your token, the reviews are signed by whoever you chose. Where the deployment holds no App key there is no question, everything runs as me.
- Use
- Click Review or Enable: a dialog asks as me or as Agent. On a listed repository, the me | Agent toggle on its row switches the rule at any time; the row reads "posted as the Agent, enabled by you" and run rows carry an as Agent pill.
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
- A colored bar and tint for the status: blue running, green done, red failed, orange stopped. Then three lines: what came out (verdict, findings, PR outcome), how it ran (type of review, as Agent, the models), the numbers (duration, cost, cache, context). The result link and the actions are on the right, the run id under them 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 your runs cost this month, 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. Your ring, red when at the cap; administrators also see one ring per person and the team total.
- 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.
Activity
- What
- Who did what, when: every agent run and every change made from the portal, newest first, for the administrators. Each line carries the colors of the run cards: blue running, green done or ok, red failed or refused, orange stopped.
- How
- Runs come from the runs table (the last 60 per person) with their outcome, cost, duration and links to the CloudWatch log, the result and the kept transcript. Changes (budget caps, administrators, cache, schedules, auto-review rules, model and review preferences, consents, ticket gestures, feedback) are recorded by the runtime the moment they run, with their outcome.
- Use
- Admin → Activity: search, filter by kind, outcome, period, person or action, Export CSV for what is listed.
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.
Pull request outcomes
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.
Budget
Change the caps ↗
In progress
this card goes away when the run endsAll runs reviews and ticket runs, as you · run id → CloudWatch log
Tell us
one row in Confluence, under your name · the FAQ and the lists are on Confluence ↗Something broke, or something is missing. Pick which, then say it in a few lines; the platform team reads the two pages.
lands on the Bugs page
Your requests
your rows on the two Confluence pages, with the status the team setIn progress
this card goes away once the ticket is deliveredWhich model runs each stage, the context and the PR templates of a repository: US to PR settings.
My US to PR tickets the tickets you started, approved or re-ran: the agent acts as you on them
or add the
ai-build label in JiraUS to PR · per repository
Repositories
What US to PR reads first on a repository (Context) and how it writes its commits, PR title and description (PR templates). Anyone sees them; the repository's admins change them.
Pick a repository to see and change its context and PR templates.