Rovo agent permissions control who can create, edit and use an agent, and the agent then acts as you or as its own account. Here's what an admin can actually set today, what gets logged, where the human in the loop sits, and how CogniRunner 6.1 agents wait for a Jira administrator before they delete anything.
Jira Cloud's API rate limit is three limits at once, and Jira gives an admin no screen that says which app spends it. This walks the headers with curl, what a 429 tells you, and CogniRunner's Maintenance screen and REST report, hour by hour and by component.
A Jira coding agent that works inside the issue: it reads your GitHub repository, plans, stages the edits, and on its default setting commits or opens a pull request only after you confirm a card, with the commit card naming every file. Walked end to end on our production build, with the pull request it opened and how to check it, and what 5.2.0 changed.
CogniRunner lets a Jira admin put OpenAI, Anthropic, Gemini, Bedrock, a self-hosted model or the zero-key Atlassian Forge LLMs behind the same workflow validator. This walks the setup end to end and says what actually changes when you bring your own key: where the data goes, who pays, which models you get, and what Runs on Atlassian has to do with it.
CogniRunner is now commercial, delivered to client teams as scoped work. Sentinel Vault stays open source. Released code keeps its licence.
CogniRunner lets a workflow validator read your JSON schema before it decides. There is a 30,000-character ceiling on what reaches the model, it cuts mid-string, and on the validator path nothing tells you. Here is how to attach a document, prove it changed the verdict, and measure what got dropped.
Until this release CogniRunner could only act when an issue crossed a workflow transition. 3.3.0 adds the two other ways an automation has always needed to run — react to an event, or run on a schedule — and a REST API that provisions both as JSON. Here is what each one actually does, what it refuses to do, and why the guard rails are shaped the way they are.
A rule that relearns your instance's quirks on every run is paying for the same lesson forever. Here is how CogniRunner stores those lessons, how the byte budget keeps them from crowding out the prompt, and the two places the behaviour is not what the names suggest.
For a year our workflow conditions evaluated a constant and gated nothing. 3.1.0 replaces that constant with ten checks that Jira runs itself. Here is what shipped, what I measured against a live Jira, and how it compares to what else is on the Marketplace.
We shipped both modules in CogniRunner pointing at the same handler. Only one of them ever invoked it. forge lint says No issues found, forge deploy validates the manifest and passes, and the gate you built is permanently open with zero log lines. Here is the probe app that proves it, and the two things that actually work.
CogniRunner's latest update brings local AI inference, a zero-key Atlassian-hosted model, and declarative AI actions that write back to Jira — all configured in plain English.
A practical, end-to-end guide to wiring large language models into Jira workflows with Atlassian Forge — using CogniRunner as the real-world case study.
Every workflow validator on the Atlassian Marketplace requires scripting. Every AI app for Jira is an assistant that can’t block a transition. CogniRunner sits in the gap between those two worlds — plain-English prompts that evaluate Jira field content, including attachments, as a real-time workflow gate.
The workflow AI agent for Jira: AI validators and post-functions, zero-AI conditions, listeners and scheduled jobs, a Coder that turns issues into pull requests, and service desk agents that earn your trust.
A workflow AI agent for Jira, on a deterministic floor. Where meaning matters, CogniRunner sends field content, attachments and related issues to an AI model and evaluates them against criteria you describe in plain English, then validates, decides and acts on the transition. Where structure is enough, 16 premade validators and 14 condition checks run with no AI call at all. When the trigger isn't a transition, listeners react to 68 Jira events and 9 git events and scheduled jobs run on cron. The Coder takes an issue to a pull request inside Jira, and Virtual Administrator agents work a service desk queue, earning each step of trust from an admin.
Block a transition when field content, an attachment or a screenshot fails your rule, and show the user the AI's reason. Agentic validators search the project with JQL to stop duplicates.
Deterministic checks evaluated by Jira itself: no AI, no per-transition cost, enforced on every surface (the issue view, REST, automation and bulk).
After a transition, the AI reads a field and writes, appends or adds list items to another, comments, creates sub-tasks or links, or writes a PDF, Word or PowerPoint file.
The AI writes JavaScript once, you test it, and it runs at zero AI cost on every transition, each step in its own isolated engine. Chain up to 50 steps.
React to 68 Jira events and 9 git events, filtered by project, JQL, changed fields or a comment regex, gated by an optional plain-English AI check, with loop brakes.
Cron in your time zone, once or once per issue of a JQL scope, with a write limit and a run report. Listeners and jobs run code steps or an AI agent.
Plans in the issue, stages edits as a diff in GitHub or Bitbucket, and commits or opens a pull request only after you confirm, in the issue panel or full screen.
Service desk agents that start in Learn and move to Shadow, Ask first and Live only when an admin decides, with a ledger, a voice and a daily budget you can read.
CogniRunner works across company-managed and team-managed Jira projects, supports all standard and custom Jira field types, analyzes the content of attached files and images, and runs on your choice of AI provider: bring your own key for Anthropic, OpenAI, Google Gemini and more, run a model on your own LM Studio, or use the zero-key Atlassian Forge LLM. Permissions, an audit log and a backup on your own Jira site keep it governable.
Jira already has ways to gate a transition. Here's honestly where each one fits — and the gap CogniRunner fills.
Good at
Fast, free, structural gates — required fields, regex, not-empty, field-equals-value.
Where it stops
Blind to meaning. They can confirm a description exists; they can't tell a real bug report from "it's broken pls fix."
Good at
Powerful, deterministic scripted logic for teams that have the Groovy/JS skills and the appetite to maintain it.
Where it stops
You write and own the code. Semantic judgment ("is this acceptance criteria testable?") is hard to express as a script at all.
Good at
Plain-English AI rules where meaning matters, plus 16 premade validators and 14 condition checks that need no AI call. Listeners on 68 Jira events and 9 git events and cron-scheduled jobs cover the ScriptRunner listener and escalation-service surfaces, with the AI writing the code. A Coder and service desk agents go further. Runs on Forge, with your own AI key or the zero-key Forge LLM, and delivered to your team as scoped work.
And then some
Reads meaning across fields, attachments, and related issues — and explains its decision back to the user in their own terms.
Describe the rule the way you'd explain it to a new hire. No Groovy to write, nothing to maintain when requirements change.
Every block, skip, or update comes with the AI's reasoning — visible to the user and saved in the log. No silent black box.
Bring your own AI provider, or keep the model call inside Atlassian with the zero-key Forge LLM. Content goes only where you point it.
Sold on the Marketplace and delivered to client teams as scoped work: the rules, listeners and jobs are built, tested, documented and handed over. They run in your Jira and stay yours.
Every part of the app, recorded end to end on a real Jira site: rules on transitions, listeners and jobs, the Coder, service desk agents, governance and backup. Start with the five-minute tour at the top of the page, or jump to the feature you need.
Anthropic, nine more providers or the zero-key Atlassian Forge LLM, tested live
A plain-English rule reads the field, is tested on a real issue, and says why it blocked
It searches the project's bugs, blocks the duplicate and names the original
Hide a transition until a field is set, then a premade check blocks a move with no comment
It reads the description and adds labels: tested first, then on a real transition
Moving the issue to Done writes a PDF from it and attaches it (Word and PowerPoint too)
Describe a step, generate JavaScript, dry-run it, save it: the transition assigns the sub-task
Search, explain, read a rule's runs, switch it off safely, export it and read it back
Give the AI your conventions once; every rule, agent and the Coder reads them
Test the built-in docs server, add one from its mcp.json, pick its tools, switch it on
Pick a Jira event, let AI decide, test it, switch it on and watch it act on a new story
Once per issue a JQL search finds, with a write limit and a run report
Execution Logs, the kill switch, and the CogniRunner panel on every issue
A connected repository, its allowed list, and Done gated on the pull request
Ask in Plan mode; the Coder reads the repository and writes the plan into the issue
Agent mode stages edits as a diff; the commit and the pull request each wait for your yes
Open a session full screen: the file tree, the conversation, and your sessions
How it writes, where it works, what it may do, its brakes, and it starts in Learn
Its proven facts and decisions, its staged drafts; moving it up a phase is a person's call
A draft checked against its voice rules, a runbook turned into suggestions, one Atlassian call allowed
A role for a Jira group, a scoped API key, and the audit log that records both
Back up on your own site, download it, and restore a deleted memory from the backup
Concrete jobs CogniRunner does on day one — each is a single plain-English rule on a transition, a Jira event, or a schedule.
Block "In Progress → Done" until the description, acceptance criteria, and test evidence are genuinely present — not just non-empty.
So that Reviewers stop bouncing tickets back for missing basics; the gate does it the moment someone tries to move the card.
On new bugs, have the AI search the project for similar reports and block with the matching issue key when it finds one.
So that Fewer duplicate tickets reaching the backlog, and the reporter sees exactly which existing issue to follow instead.
When an issue hits Done, summarize the work into a customer-facing Release Notes field automatically.
So that Release notes write themselves as work completes, instead of being reverse-engineered from commits at ship time.
Reject transitions when a field — or an attached document or screenshot — contains PII, secrets, or placeholder text like "TBD".
So that Sensitive data is caught at the workflow boundary, not in a quarterly audit after it's already shared.
Require steps to reproduce, expected vs. actual behavior, and an affected component before a bug can leave triage.
So that Engineers receive bugs they can actually act on, cutting the back-and-forth that stalls the first day of every fix.
Confirm an attached spec, mockup, or contract is the real thing and covers the required sections — reading the file, not the filename.
So that "Looks done" stops meaning "a file is attached" and starts meaning "the right, complete file is attached."
A listener on Issue created: an AI condition spots a vague story, then generated code adds a needs-details label and asks the reporter for steps, expected vs. actual, and logs.
So that The reporter is asked for the missing details within seconds of filing — before anyone in triage has even seen the ticket.
A job every weekday at 10:00, scoped by JQL to open issues with no assignee: set priority High, add a needs-owner label, and comment asking someone to claim it — once per issue.
So that Ownership gaps surface every morning, automatically, instead of when a customer escalates.
A scoped job in AI-agent mode: "ask the assignee for a status update in a short comment and add the label stale" — allowed only get_issue, add_comment, add_labels.
So that The agent decides what to say per issue; the allow-list decides what it can touch. Nothing else is possible.
A developer opens the Coder on the issue, asks for a plan in Plan mode, then lets Agent mode stage the edits and confirms one commit and the pull request.
So that The plan, the diff and the pull request link live on the issue the work came from, and nothing reaches the repository without a confirmation.
A condition hides Done until the issue's pull request is merged, and a premade validator checks that its build passed and its review comments are resolved.
So that Jira's status and the repository stop disagreeing, with no AI call on the transition.
A Virtual Administrator works the IT help queue in Shadow: it drafts each reply in your team's voice and a person approves or rejects it.
So that You read its drafts and its ledger before you trust it, and promote it to Ask first or Live only when it has earned it.
CogniRunner integrates into Jira's native workflow editor. Add a validator or condition in three steps. Listeners and scheduled jobs don't belong to a transition, so they live in the admin panel's own Listeners and Scheduled Jobs tabs instead; the Coder opens from any issue, and agents live under Agents.
Select a transition and click the Rules panel on the right side. You'll see rule categories: Restrict transition, Request input, Validate details, and Perform actions.
Click the + button next to "Validate details" (for validators) or "Restrict transition" (for conditions). Find CogniRunner Field Validator under Marketplace Rules.
For AI validators and post-functions: select the field and describe your rule in plain English, optionally attaching context docs. For conditions and premade checks: just pick the deterministic check — no prompt at all. Prefer not to touch the workflow editor? Use + Add Rule in the admin panel's guided wizard.
When you add or edit an AI validator, you'll see the configuration form with three settings.
Which Jira field the AI should evaluate
Your criteria described in natural language
Auto, always or never; a note under it says whether Auto will run your prompt as an agent that searches Jira or as a plain check
Conditions decide whether a transition is even offered — and in CogniRunner they are deterministic: zero AI, zero per-transition cost, zero added latency. Jira evaluates the check itself, so it is enforced on every surface — the issue view, the REST API, automation rules, and bulk operations alike.
You don't write a prompt; you pick one of 14 checks. And because Jira runs the check natively (no app code executes), conditions produce no execution-log entries. The 16 premade validators beside them (field is required, changed, matches a pattern, one of a list, a date within N days, an attachment or a comment is required, and more) run in the app, also with no AI call.
The three field checks work on custom fields, with support verified per field kind:
| Field kind | Has value / Is empty | Equals a value |
|---|---|---|
| Text (single-line) | Yes | Yes — case-insensitive |
| URL | Yes | Yes |
| Date | Yes | Yes |
| Number | Yes | Yes |
| Select (single choice) | Yes | Yes |
| Radio buttons | Yes | Yes |
| Multi-value kinds (multi-select, checkboxes, labels…) | Yes | No — use has value / is empty |
The field picker annotates unsupported fields with “Not supported for conditions” instead of letting you configure a check that can't run.
The field selector dropdown shows all fields available on your project's edit/view screens, grouped by system fields and custom fields. Each entry shows the field name, its internal ID, and its type.
The validation prompt is where you describe your quality criteria in natural language. The AI evaluates the field content against this prompt and returns a pass/fail result with reasoning.
When a rule needs context beyond the field itself, CogniRunner goes agentic: the AI autonomously builds and runs JQL queries against the issue's own project — over multiple rounds — to find similar or related work before deciding. The Jira Search setting has three modes.
This is the difference between “is this field filled in?” and “has someone already reported this?” — a question that previously needed a human to remember, search, and judge. Catching a duplicate at the point of creation saves the triage meeting, the merged tickets, and the work that gets done twice.
| Mode | Behavior |
|---|---|
| Auto-detect from prompt | CogniRunner reads your prompt and turns JQL search on only when it asks to find duplicates, similar or existing issues; a note under the setting says which way Auto will run your prompt. This is the recommended setting. |
| Always enabled | JQL search is always active, regardless of prompt wording. The AI can run up to 3 rounds of JQL queries to find related issues. This is also the only mode in which a validator may call MCP tools. |
| Always disabled | No JQL search is performed. Validation is based solely on the field content and prompt. Fastest option. |
When agentic search is active, the AI generates and executes JQL queries to find related issues. It can run up to 3 rounds of queries, each returning up to 10 results, and is confined to the rule's own project for safety. The AI then uses what it finds to inform the decision — and the full query trail is logged.
When you select Attachment as the field to validate, CogniRunner downloads and analyzes the actual content of attached files. The AI can read documents, spreadsheets, presentations and plain-text files, and understand images.
Every other workflow check treats an attachment as a checkbox: a file is present, so the gate passes. That's exactly how an empty template, a stock photo, or last sprint's spec sails through. Reading the file closes that gap — the requirement becomes the right, complete document, not any document.
| Format | Extensions |
|---|---|
.pdf | |
| Word | .docx, .doc |
| Rich Text | .rtf, .odt |
| Excel | .xlsx, .xls |
| CSV / TSV | .csv, .tsv |
| PowerPoint | .pptx, .ppt |
| Plain text | .txt, .md, .log, .json, .xml, .yaml |
| Format | Extensions |
|---|---|
| PNG | .png |
| JPEG | .jpg, .jpeg |
| GIF | .gif |
| WebP | .webp |
All image formats are processed via AI vision — the AI understands image content, not just metadata.
Unsupported file types are gracefully skipped — the AI receives metadata about skipped files (filename, size, type) so it can still reference them in its reasoning.
When a user attempts a workflow transition, CogniRunner evaluates the configured field against your prompt. If validation fails, the transition is blocked and the AI's reasoning is displayed as an error message.
Validators check; post-functions act. A semantic post-function runs after a transition: the AI reads a source field, decides whether to act, generates a value, and writes it to a target field, all described in plain English. It keeps what is already there: text can be appended to instead of replaced, and labels or other lists can have items added or removed.
This is the busywork that quietly eats team hours: copying a summary into release notes, keeping an audit field current, turning a description into a checklist. Each is a tiny task no one wants to own — and the first thing dropped under pressure. Hand it to a post-function and it happens consistently, on every transition, with the reasoning logged.
When should this run? The AI evaluates the source field and decides to update or skip.
What should it write? The AI generates a value to the rules you describe.
Where does it go? Schema-aware formatting writes the value into the field you choose: replace, append, or add and remove list items.
It reads the description and adds labels: tested first, then on a real transition
Moving the issue to Done writes a PDF from it and attaches it (Word and PowerPoint too)
For deterministic automation, the AI writes JavaScript once at setup. After that it runs on every transition at zero AI cost. Chain up to 50 steps with variable passing, a built-in code editor with autocomplete, and a sandboxed Jira API. Every step runs in its own isolated engine with a time budget, a 64 MB memory limit and a recursion limit, and a failing step names its line.
This is the bridge for platform engineers who'd otherwise reach for ScriptRunner: you describe the automation in plain English, the AI drafts the code, and you keep an editor open to read, tweak, and test it against real issue data before it ever touches production. The output is plain JavaScript you fully control — predictable on every run, with no AI in the hot path once published.
api.searchJql pages through every result; api.countJql counts matches in one request.
Read and update issues, comment, transition, create, clone, link, log work and more through api.*.
Create or update Confluence pages from a step.
Start from a fill-in recipe; skills and memories steer the generated code.
A failing Test Run can be repaired by the AI, which re-runs the test; a passing step can be saved as a skill.
A dry-run Test Run intercepts writes; each step runs in its own engine with firm limits.
Describe a step, generate JavaScript, dry-run it, save it: the transition assigns the sub-task
A workflow rule runs when an issue crosses a transition. A listener runs when something happens: an issue is created, a comment lands, a sprint closes, a request type changes (any of the 68 product events Forge exposes for Jira, Jira Software and Jira Service Management), or a pull request is opened, merged or built in a connected GitHub or Bitbucket repository.
This is the ScriptRunner Script Listener surface, rebuilt around AI: you describe what should happen, the AI writes the sandboxed code — or acts as an agent — and the listener carries its own loop guard, brakes, and simulation mode so a mistake cannot run away.
Issues, comments, worklogs, attachments, issue links, projects, versions, components, sprints, boards, users, custom fields, issue types, filters, configuration, JSM request types, and 9 git events delivered by a signed webhook. Pick one or several per listener.
Projects, issue types, a JQL the issue must match, changed fields (on Issue updated) and a comment regex (on comment events), all evaluated before a single AI call. The tab counts how many events the filters turned away since the last save.
A plain-language yes/no — "the issue is a Story and its description is vague" — that the model evaluates before the run. One cheap classification per event; it fails closed.
Code steps use the same sandbox api.* as static post-functions, bound to the event's issue, with api.context.event carrying the raw payload. Or hand the event to an AI agent with an allow-list of actions. A listener never posts the same comment again while its last copy is still the newest one.
Ignore self-generated events is on by default. Brakes cap a five-minute window at 30 runs of one listener on one issue and 120 runs per listener, and a run skipped by a brake leaves a log row that says why. Every accepted event is claimed once, so a redelivered event never runs twice.
Run test builds an event from a real issue and runs everything in simulation, in the background, showing Queued, Running and then the result. Once the event has fired for real, inspect the last payload, with capability tokens stripped from what is stored.
Pick a Jira event, let AI decide, test it, switch it on and watch it act on a new story
A job runs on a five-field cron expression in an IANA time zone — either once, with no current issue, or once per issue of a JQL scope, the way an escalation service does. Each run executes code steps or an AI agent, exactly like a listener.
Presets from every five minutes to monthly, or a custom five-field expression, in the IANA time zone you choose, with a preview of the next runs. A schedule that never runs, such as 31 February, or an unknown time zone is refused when you save.
Scope the job with JQL and it runs once per matching issue, each with its own current issue and outcome. Unscoped jobs have no current issue — they search and re-bind with api.forIssue().
Queue an immediate run of a saved job and watch the result arrive; Run now cannot be pressed twice while a run is in progress. A write limit of 0 makes the job read-only: any change it tries is refused and logged.
The history shows each issue's outcome in full: how many were processed, how many changes were made, and an expandable change log per issue. An issue the run did not reach reads not reached, and one an agent declined reads declined, never failed.
The platform ticks every five minutes; each due minute is claimed once, so duplicate ticks never double-run a job. A job that missed ticks replays at most one hour and one run.
Describe the step in plain English, Generate, test in simulation — the same describe → generate → test → fix loop as static post-functions, with skills auto-attached.
Once per issue a JQL search finds, with a write limit and a run report
* * * * * schedule runs once per tick. Keep runs idempotent (check for a marker before writing): a retried or manually re-driven run must not duplicate a comment.Code steps are deterministic and free to run; an agent is for the cases where the right action depends on reading the issue. Write instructions in plain language, tick the actions the agent may take, and it works through the event or the scoped issue in rounds — every tool call recorded.
The model receives your instructions plus the event or job context as fenced, untrusted data, and can act only through the actions you ticked. These are the thirteen Jira actions; with a git connection, Confluence, web search, MCP or knowledge switched on, their actions can be ticked too. finish is always available and ends the run with a summary.
Grey actions only read Jira; magenta actions write. Defaults: get_issue, search_issues, add_comment.
maxRounds is 1–8, default 5. Each round is one model call that may invoke tools; when the cap is reached the run ends and says so.
Every run lands in the execution log with an outcome (done, nothing to do, declined or failed; a declined task is never counted as an error), a short summary, every tool call with its arguments, and the change ledger of what was written. A run in simulation opens with Simulated, nothing was written.
The Coder works inside the Jira issue. It reads your GitHub or Bitbucket Cloud repository, plans in Plan mode, stages its edits as a diff in Agent mode, and commits or opens a pull request only after you confirm. Open it from the issue panel, or full screen.
The ticket, the plan, the diff and the pull request link stay together on the issue the work came from, so a reviewer or a teammate opens the same conversation instead of asking what happened.
Plan mode only reads the repository and writes its plan into the issue description. Agent mode may stage edits and, once you confirm, commit them.
Edits are staged in the conversation, never straight to the repository. Commit to branch or Commit and open PR asks you once and names every staged file, and one request never makes the same commit twice.
Ask first opens a card before every write. Auto-edit lets staged file edits through while commits, pushes and Jira writes still ask. Under Bypass the actions that need an admin, such as creating a repository or approving a pull request, still do.
Type @ to attach up to four repository files, add skills and issues from the composer, and let it search the web when web search is on for the site.
A new conversation starts with a searchable picker grouped by workspace, allowed repositories first. A Jira admin can allow one with a single confirmation, and the Coder can create a repository with the connection's credential once an admin confirms.
It keeps its goal across long runs and carries on in a new segment when time runs out. At its token limit it stops and offers Continue. You can steer a running turn, or Stop it.
Ask in Plan mode; the Coder reads the repository and writes the plan into the issue
Agent mode stages edits as a diff; the commit and the pull request each wait for your yes
A project page with Files, Conversation and Changes side by side. The side column hides and resizes from a handle on its edge, and a file the Coder changed opens with the diff of its last commit. You can also start coding without an issue.
The Sessions button lists your own conversations and the ones shared with you, on an issue or not, with a search and older sessions on request.
Share a session by name or with everyone who can see the issue. The person who started it, or a Jira admin, can delete it: the conversation and its uncommitted files go, while commits, pull requests and Jira comments stay.
Sessions update live while a turn runs. When the Coder needs your answer it ends its turn on the question, shown at the top of the turn and above the message box.
Open a session full screen: the file tree, the conversation, and your sessions
Connect GitHub or Bitbucket Cloud under Agents, Setup, with a list of the repositories CogniRunner may use. The token is checked before it is stored and never shown again. From then on Jira knows what happens to the pull request, and the Coder can work in those repositories.
Pull request opened, updated, closed, merged, reviewed or commented, a branch pushed, a check run or a pipeline completed: delivered by a signed webhook, they run listeners like any Jira event.
Three conditions hide a transition until the pull request is merged, approved or its build has not failed. Four premade validators block it until the build passed, it is approved, its comments are resolved or it is merged. None of them calls an AI.
When nothing is on record for the issue, the git validator asks GitHub or Bitbucket for the pull request, preferring an open or merged one and a branch that names the issue over a title that does.
The premade Review every opened PR listener reads the diff of each opened or updated pull request and leaves one review comment, on the repositories you pick.
Each person can connect their own git sign-in in Your setup, so a commit they confirm in the Coder carries their name. Creating a repository always uses the connection's own credential, after an admin confirms.
On a Forge app repository, a deploy pipeline on Agents, Setup deploys with the FORGE_EMAIL and FORGE_API_TOKEN secrets you add to that repository's CI yourself; CogniRunner never sees the token. It says why when a setup fails. Removing a repository from the allowed list also removes its webhook.
A connected repository, its allowed list, and Done gated on the pull request
A Virtual Administrator works a service desk queue, a JQL filter and its mentions on a schedule. Every new agent starts in Learn, reading and keeping notes, and moves up only when an admin decides.
You see its judgment before you rely on it: the replies it would have sent, what it learned about your site and the evidence behind each fact, what it changed, and what it is waiting on.
Reads the projects it is allowed to read, keeps notes and proposes facts, rules and knowledge.
Drafts no replies, asks no one, files and changes nothing.
Also drafts replies and records the changes it would make, for a person to review.
Posts nothing, changes nothing, files nothing.
Also asks people questions, files change proposals and runs a request a person approved.
Posts no answers and makes no change nobody approved.
Also posts answers and makes changes within its powers, its working hours and its caps.
Never deletes, changes configuration or touches users and groups without a person's approval.
What it is doing now and on which issue, its phase with a control to move it, a tick timeline with Run now and Pause, Staged drafts with Approve and Reject, What it did, and one Needs you list for everything waiting on a person.
Facts with the evidence behind them, decisions, open questions, holds on an issue or a person, people notes and standing rules. Add, correct, strike, pin or dismiss; the agent never overwrites what a person wrote. A scratchpad shows what it noticed on each run.
Up to 40 REST operations from Jira, Jira Service Management, Assets and Confluence, picked by a Jira administrator. Deletes and changes to configuration, users or groups wait for a Jira administrator's approval and expire after 24 hours; Try a request shows what a call would pass without sending it.
A daily AI token budget checked inside each turn, an hourly limit, working hours, invited work only and a second check on public replies. No agent promotes itself.
Studies the site once a day and suggests memories, documents and skills, which wait up to 14 days for an admin to save or decline. It posts nothing and changes nothing, and a site has at most one.
Notices when one person deletes 10 or more issues within 10 minutes, or 3 in a protected project, files an incident and tells the organisation admins and the affected project leads. Only organisation admins see its card.
How it writes, where it works, what it may do, its brakes, and it starts in Learn
Its proven facts and decisions, its staged drafts; moving it up a phase is a person's call
An agent writes the way people on your site write, and learns what your team already wrote down. Nothing it proposes changes anything until a person accepts it.
Paste replies people here wrote, ban phrases, tighten the word limit, and check a draft against the same rules the agent's own replies must pass before they go out.
Once a week an agent compares its recent replies with how people on the site write and may propose one writing rule, shown with proof that it catches the agent's own replies and none of the people's.
Paste a runbook, FAQ or handover note, or a text file, and the agent suggests facts, decisions, notes about people and standing rules for its ledger. Nothing is kept until you accept it.
A draft checked against its voice rules, a runbook turned into suggestions, one Atlassian call allowed
Listeners and jobs belong to the CogniRunner installation, not to a workflow, so they get their own bearer-token API. Push them as JSON from CI or a migration script: single objects, arrays of up to 100, partial updates, enable, disable, test, run, and read-back of logs, samples and catalogues. The same API serves the release notes and the audit log, and lets an editor dry-run a validator or an AI post-function against an issue without writing to it.
Workflow rules — validators, conditions, post-functions — still attach through Jira's own workflow REST API with your Jira credentials; CogniRunner's API can then test and register them.
Settings → API access, admin only. Each key carries a role and a reach (its creator's own rules or everyone's) and expires after 90 days by default. Only the SHA-256 hash is stored; the plaintext is shown once. Up to 25 live keys, each revocable on its own.
Authorization: Bearer cgr_… (or X-Api-Key) against the Rules API URL shown for that installation. No token, or a wrong one, is a 401 with no detail.
POST a config, read the returned id back with GET &id= to check the complete saved record, and include that id on reruns to update the same rule. A key acts with its creator's current role, checked on every call.
| Method | Query | Body | Result |
|---|---|---|---|
| GET | ?resource=events · ?resource=actions | — | Catalogues of the 68 events and the 13 agent actions |
| GET | ?resource=listeners · &id= | — | Slim list, or one full record |
| POST | ?resource=listeners | One config, or an array (≤100) | Created / upserted — 201, 200 or 207 |
| PUT | ?resource=listeners&id= | Partial config (filters, agent, schedule, scope merge) | Updated |
| DELETE | ?resource=listeners&id= | — | Deleted |
| POST | ?resource=listeners&id=&action=enable | disable | test | test: { issueKey, eventType, event? } | New state, or a simulated run |
| GET · POST · PUT · DELETE | ?resource=jobs… | Same shapes | Same results |
| POST | ?resource=jobs&id=&action=run | preview | preview: { cron, timeZone, count } | 202 { taskId }, or the next runs |
| GET | ?resource=tasks&id=<taskId> | — | Queued-run status and result |
| GET | ?resource=logs[&ruleId=] | — | Execution logs, newest first |
| GET | ?resource=samples&eventType= | — | Last captured payload for that event |
| GET | ?resource=whoami | — | The token's identity |
# Push a listener, then a job, to one CogniRunner installation
curl --fail-with-body "$RULES_API_URL?resource=listeners" \
-H "Authorization: Bearer $RULES_API_TOKEN" \
-H 'Content-Type: application/json' \
--data-binary @listener.json
curl --fail-with-body "$RULES_API_URL?resource=jobs" \
-H "Authorization: Bearer $RULES_API_TOKEN" \
-H 'Content-Type: application/json' \
--data-binary @job.jsonOne item created or upserted
Array saved, PUT updated, state changed
Batch partly failed — errors[] names each rejected index
Validation failed — the same message the admin UI shows
Missing or unknown token, no detail
Storage busy: Retry-After and a sentence; nothing is authorised
action=run) answers 202 { taskId }; poll ?resource=tasks&id= for the result. And a 207 is not a success: inspect both the saved rows and the indexed errors array before marking a batch done.The Rules tab is a real control plane, not just a list. Enable, disable, delete, import, export — and every action tells the truth about what it did to your Jira workflows.
Pause a rule without losing its config. For conditions, the disabled flag is written into the workflow rule itself, so Disabled is enforced by Jira — never a lie. A failed write refuses rather than half-applies.
Per-row and bulk Delete remove the rule from the Jira workflow, not just from the list — behind a preview dialog that predicts the outcome for each rule before you commit.
See real site-wide pressure against the registry's true capacity — 500 rules, 240 KiB. Import checks the cap before attaching anything.
Each row shows the rule in its own words (a premade rule's name, a code step's names, a post-function's prompt) and its owner, and every rule keeps its own last 20 runs, so a busy rule never pushes a quiet one out of view. Explain gives a plain-English summary.
Find rules attached outside the panel (REST automation, copied workflows) and claim them in one click, with a report of what was skipped and why. A scan reads up to about 300 workflows at a time, then offers Scan the rest.
Export rules as self-contained JSON with every setting they need, code steps included. Import shows a preview, rebinds fields to the target site's IDs, and checks a large file in parts.
CogniRunner rules are ordinary Forge workflow rules — so you can attach them with Jira's own workflow REST API, using your Jira credentials, no CogniRunner API involved. Bulk-provision a rule across fifty projects, migrate rules between sites, or keep them in version control. This is distinct from the bearer-token Rules REST API, which provisions listeners and scheduled jobs — things that have no transition to attach to.
The Rules tab's “Automating rule creation” panel gives you everything install-specific: this installation's extension ARIs with copy buttons, the ruleKey and target slot for each rule type, and the size caps (a rule's config must stay under Jira's 32 KB cap; the panel manages up to 500 rules).
id inside the rule's config: without it the rule can be claimed but never disabled, because that id is the identity the runtime matches on.exprProp and exprKind (plus valueNum for number fields). A mismatched exprKind is the one way a condition can fail closed — copy the config shape from a UI-made rule rather than hand-crafting it.The CogniRunner admin panel is the hub for every rule, listener, job and agent on your site. Open it from the Jira Apps menu, from the app's page under Jira administration, or with Configure or Get started on CogniRunner's row in Manage apps; its header links to the documentation and to support. It has 14 tabs; a person sees the ones their role can use, and someone with no CogniRunner role sees only Your setup.
Every validator, condition and post-function across all workflows: filter by type or ownership, edit, disable or delete (with workflow detach) inline, one at a time or in bulk. Listeners, scheduled jobs and agents have tabs of their own.
Create a workflow rule without touching the workflow editor — pick project, workflow, transition, and type, then configure and publish. Listeners and jobs are created in their own tabs.
A shared documentation library, reusable Skills, learned Memories, baked field guide packs and MCP servers give the AI grounded, instance-specific context.
The last tab of the admin panel is about the reader, not the site. Anyone who can use CogniRunner reaches it, a person with no CogniRunner role lands on it, and the Coder's menu opens it from the issue panel and from full screen.
Connect your own GitHub or Bitbucket sign-in, so a commit or pull request you confirm in the Coder is made as you rather than as the site's connection.
For the deploy pipeline on a Forge app repository: CogniRunner stores no Atlassian API token. You add FORGE_EMAIL and FORGE_API_TOKEN to that repository's CI secrets yourself, and identities saved by earlier versions are deleted.
What the Coder writes on the issue (every step, one report per turn, or nothing beyond the panel) and how much it may do before asking in a new conversation (Ask first, Auto-edit or Bypass), each with a choice to use the default.
An app that writes to Jira, commits code and answers customers has to be governable. CogniRunner's controls sit in the same admin panel: permissions for people and Jira groups, an audit log, REST API keys scoped to a person's own role, the Jira API and AI use you can read, and a backup of the whole setup on your own site.
Viewer, Editor or Admin for a person or a Jira group, over their own rules or everyone's, with a guard that keeps the last admin.
What people changed in CogniRunner and what the app did by itself, searchable and exportable.
Each key carries a role and a reach, expires after 90 days by default, and can never do more than the person who made it can do today.
Everything you configure, kept in a hidden project on your own Jira site, restored after a reinstall or moved as one file.
Settings, Maintenance shows CogniRunner's Jira API use hour by hour over two weeks, which part of the app spent it, and any time Atlassian slowed it down.
The version your site runs, what changed in it, and a warning when your browser is showing an older build.
A role for a Jira group, a scoped API key, and the audit log that records both
Give a person or a whole Jira group Viewer, Editor or Admin access, over everyone's rules or only their own. Every grant is checked against Jira before it is saved, and the list is read again after every change.
This is what lets a Jira admin let go safely. Team leads can author and tune their own workflow rules without an admin in the loop, and without the keys to everyone else's rules or the AI provider settings — so governance scales past a single gatekeeper.
Reads rules, listeners, jobs, logs and knowledge, with no add, edit or delete controls.
Creates and changes their own work, or everyone's when the grant says so. Writing code steps still needs an admin.
Everything, including permissions, AI providers, MCP, the audit log, and creating or moving agents.
The Audit log tab lists what people changed in CogniRunner and what the app did by itself: a listener or job run that wrote to Jira, a Coder commit, a research page it saved. Each row says who or what did it, when, and whether it went through, and names the rule, agent, document or person it is about.
Search by name, filter by kind and dates. Times are shown in UTC and say so, with your local time when you point at them.
Export to CSV. An export that could not read everything says so instead of downloading a partial file.
The app's own routine entries have their own daily budget in the log, so a busy listener can never crowd out a person's entry.
Your CogniRunner setup survives an uninstall. The app keeps a backup of everything you configure in a hidden project on your own Jira site that only Jira administrators can see. It never leaves Atlassian.
Rules, listeners, jobs, agents, docs, skills, memories, settings and Coder sessions.
CogniRunner finds the backup and offers to restore it. Listeners, jobs and agents come back switched off until you turn them on, and keep the permissions of the person who made them. A new install also offers to register the CogniRunner rules still on your workflows.
A Backup and restore card shows when the last backup ran and its size, with Back up now, and Download or Upload of your whole setup as one file. The same view shows Jira API usage and the version you run.
API keys and tokens are never backed up, nor are execution logs, usage history or the audit log. After a reinstall you enter the keys again and mint new API tokens.
Back up on your own site, download it, and restore a deleted memory from the backup
CogniRunner carries its own release notes. Settings, Maintenance shows the version your site runs and what changed in it, and says when your browser is showing an older build; anyone can open What's new from the admin panel's header. Every rule export is stamped with the real version.
Personal data reporting to Atlassian is switched on: accounts Atlassian reports as closed are erased, and the app asks for six fewer permissions while adding one, to report personal data, which a site admin approves once in Manage apps.
Stricter handling of credentials, personal data and the licence: deploy pipelines read FORGE_EMAIL and FORGE_API_TOKEN from your own CI secrets, keys move to Forge's encrypted secret storage, background work stops on an inactive licence, and the admin header links to documentation and support.
Self-hosted providers without a key, exports of any size that re-import, and every rule test checked against what you can open in Jira. 1.27.1 and 1.27.2 the same day: conditions never labelled as AI, and testing one code step runs the steps before it first.
Your setup survives an uninstall: backup and restore on your own Jira site, and rules still on your workflows can be registered again after a reinstall.
Agents learn your team's voice and your runbooks and make the Atlassian calls you allow; a guard dog and a growth bot join them; code steps run in their own isolated engine; most screens fit a phone. Patch releases up to 1.26.16 followed.
A Reasoning effort setting for every model that supports it, and every new Virtual Administrator starts in Learn.
Each agent gets a home: a phase you control, a ledger and a scratchpad you can read and edit.
The REST API follows CogniRunner's own permissions: keys with a reach, a 90-day expiry and AI limits. Cut-off AI replies are never used as if complete.
A new look for the Coder in the issue panel and full screen: one header, one composer, steps you can read at a glance.
Jira API usage hour by hour, and an audit log of what people did and what the app did by itself.
Permissions rebuilt for people and Jira groups, and the app carries its own version and release notes.
Any OpenAI-compatible server, Ollama and Goose Swarm as providers; Your setup; the MCP tab; per-project knowledge, provider, git and write limits.
The Coder workspace: Files, Conversation and Changes side by side, and one confirmed commit for the whole staged set.
The Virtual Administrator, and CogniRunner's reach into Confluence.
The Coder, a Coder post-function, git connections, webhooks, pull-request review and git rules.
Two editions, Standard and Coder, and a separate agent model per provider.
Listeners, scheduled jobs and a Rules REST API.
Rule management you can trust, and conditions that actually work.
Give the AI grounded context. Upload API docs, JSON schemas, business rules, or code snippets once, then attach them to any rule so the AI validates and generates against your standards, not just its training data. Built-in documents ship with the app; an admin can switch one off, and switched-off built-ins are listed apart so they can be turned back on.
CogniRunner doesn't just run on a model's generic knowledge: you teach it. Skills are reusable instruction packs; Memories are facts it learns about your instance. Rules, agents and the Coder read them, so their output fits how your Jira actually works.
Teach the code generator domain-specific patterns — Jira REST calls, ADF formatting, duplicate detection. Attach a skill to a rule, or let CogniRunner auto-match by the step's description. Ships with built-ins; add your own once and reuse them everywhere.
Short facts about this Jira (custom field IDs, option lists, workflow quirks), captured once and injected into every generation, so the AI stops repeating the same mistakes. Add them yourself, keep the ones a fix proved, or switch on learning as it runs; that switch is off by default.
Give the AI your conventions once; every rule, agent and the Coder reads them
CogniRunner sits between your AI and the outside world. Through the Model Context Protocol (MCP), a rule, an agent or the Coder can call real tools, and CogniRunner brokers every call, so your AI provider never sees the tool's URL or credentials. The admin-only MCP tab holds three built-in integrations and any remote server you add by pasting its mcp.json entry. Both LeanZero MCPs are open source: set them up yourself, or use a hosted demo key. Jump to the setup steps.
Live library & SDK docs. The AI checks code against the current documentation for any library — not the model's training cutoff.
resolve-library-id · query-docs
Real-time web search plus page and PDF extraction, so a rule can research a topic or verify a claim while it runs.
get-web-search-summaries · full-web-search · get-single-web-page-content · get-pdf-content
Read attached files and generate real DOCX, PDF, Excel & PPTX — a rule can produce a deliverable and attach it to the issue.
read-doc · create-doc · create-pdf · create-excel · create-pptx
Test the built-in docs server, add one from its mcp.json, pick its tools, switch it on
Each MCP is configured like an mcp.json entry — a URL and a key. There are two routes, and they are not interchangeable: the hosted bridge works with every AI provider, while the local route works only with LM Studio but keeps the work on your own machine.
Works with every provider
LM Studio provider only
| Integration | Required mcp.json entry name | Where to get the server |
|---|---|---|
| context7 | context7 | Upstash's own hosted service, pre-filled in the card. |
| web-search | web-search | MCP Web Search — full setup guide |
| doc-readerserver repo: doc-processor | doc-reader (not “doc-processor”) | MCP Doc Processor — full setup guide |
command has no machine to run on. Remember to accept the bare hostname as well as host:port in the server's rebinding protection.Open source, MIT. Install it locally in five minutes, or run it as an always-on HTTPS service — the documentation covers both, plus every setting, the code, and this integration end to end.
Open source, MIT. The same two deployment routes, the 17 tools, the single-use attachment capability flow, and how a rule attaches a generated document back to the issue.
Both MCPs run on a Mac Studio behind a Tailscale Funnel, and a free demo key is issued on the spot — copy it when it appears, it is shown only once (a copy is emailed where possible). It is an evaluation surface rather than infrastructure — shared rate limits, no SLA, and files written to our disk — so move to your own instance before anything matters. Keys: web-search · doc-processor.
Every run (validator, post-function, listener, scheduled job, agent or Coder turn) is logged with full context: its outcome, the AI's reasoning, the JQL it ran, and an execution trace. Runs a person should look at come first, repeated quiet passes fold into one row, and the job queue shows what is waiting or running, with a kill switch. Deterministic conditions are evaluated natively by Jira, so they produce no log entries: no app code runs.
This is what makes AI-in-the-loop something you can defend rather than something you have to trust blindly. When a user asks “why was I blocked?” the answer is one entry away, verbatim — the field it read, the queries it ran, the verdict, and a suggested fix. Tuning a rule stops being guesswork.
Execution Logs, the kill switch, and the CogniRunner panel on every issue
The site-wide view keeps the newest 50 runs, and every rule also keeps its own newest 20, so a busy rule never pushes a quiet one out of view.
CogniRunner extracts readable text from any Jira field type and sends it to the AI for validation. All field values are converted to plain text before evaluation.
| Category | Field Types |
|---|---|
| Text | Single-line text, Multi-line text, URL |
| Rich Text | Description, Comments, and other ADF fields — full text extraction from rich content |
| Select | Select list (single/multi), Radio buttons, Checkboxes, Cascading select |
| People | User picker (single/multi), Group picker (single/multi), Reporter, Assignee |
| Date & Time | Date picker, Date/Time picker |
| Numeric | Number, Time tracking (original estimate, remaining estimate, time spent) |
| System | Priority, Status, Resolution, Issue type, Labels, Components, Versions, Sprint |
| Reference | Issue links, Parent issue, Project picker |
| Files | Attachments — with full content analysis |
| Third-Party | Checklist for Jira, Xray, Assets/Insight, ScriptRunner, Tempo, Elements Connect, and more |
| Custom | Any custom field with a readable value — extracted generically |
| Limit | Value | Notes |
|---|---|---|
| Max attachment size (per file) | 10 MB | Files larger than 10 MB are skipped |
| Max total attachment size | 20 MB | Combined size across all attachments per validation |
| Validation time budget | 20 seconds | Field read, JQL rounds, MCP tools and the AI answer share it, inside Forge's 25-second limit; when it runs out the transition is allowed and logged |
| JQL search rounds | 3 rounds max | Each round can execute multiple JQL queries |
| JQL results per query | 10 issues | Top 10 matching issues returned per query |
| Static post-function steps | 50 steps | Chained operations per static post-function |
| Execution log history | 50 site-wide · 20 per rule | Every rule keeps its own newest 20 runs |
| Prompt log truncation | 200 characters | Prompts in log entries are capped at 200 characters (field values at 300) |
| Rule registry capacity | 500 rules · 240 KiB | Byte-accurate usage meter on the Rules tab; imports check the cap before attaching |
| Listener brakes | 30 / listener on one issue · 120 / listener | Per five-minute window; further runs are suppressed and logged |
| Code step memory | 64 MB | Each step runs in its own isolated engine with a time budget and a recursion limit |
| Scheduled job scope | 100 issues | Per run of a JQL-scoped job; unscoped jobs run once with no current issue |
| Scheduler granularity | 5 minutes | Platform tick; a missed window replays at most one hour and one run |
| AI agent rounds | 8 max (default 5) | One model call per round; the run ends when the cap is reached |
| Rules REST API | 100 items · 25 keys | Items per batch request; live keys per installation, 90-day expiry by default |
| REST AI actions | 20 / 10 min · 200 / day | Per key; refused requests are recorded in the audit log |
CogniRunner ships with no embedded API key. Connect your own key from any supported provider, run a model on your own server, or use the zero-key Atlassian Forge LLM that runs inside Atlassian's platform. Each provider keeps its own key and settings, so switching never loses them, and each can run a small default model for rules and a stronger one for agents and the Coder, with a reasoning effort where the model supports one.
For a security or platform team, this answers the first question they'll ask: where does our issue data go? The answer is wherever you decide — your own provider account under your existing data agreement, or never leaving Atlassian at all with the Forge LLM. No third party sits between Jira and the model, and switching providers later is a dropdown, not a migration.
The first Jira app to integrate LM Studio — inference and your field data stay on your own hardware. Absolute privacy and zero per-token cost, for the security- and budget-conscious. The multi-model pool spreads validator calls across every model you have loaded, so one busy model never becomes the bottleneck, and LM Link puts several machines behind one endpoint.
One of the first apps to ship the Atlassian Forge LLM provider — AI that runs inside Atlassian's platform with no API key, and a model call that never leaves it.
Claude models, your key
Your OpenAI API key
Your Gemini API key
Your Azure deployment
Converse API, your account
One key, many models
Ollama cloud or your own server
Your own Goose Swarm node
Anything that speaks the OpenAI chat API
Self-hosted on your own hardware, with LM Link
Zero key, no egress: runs inside Forge
Anthropic, nine more providers or the zero-key Atlassian Forge LLM, tested live
The complete reference: every provider and where your data goes, how a validation run actually unfolds, the full post-function and automation rulebook, rules, skills and memories, the permission model, the limits, listeners, jobs and the REST API, and what to do when a verdict surprises you. 83 sections.
Every rule, key and number here is taken from the app's own source and checked against it.
The workflow AI agent for Jira: AI validators and post-functions, conditions that run inside Jira with no AI at all, premade checks that need no AI call, listeners, scheduled jobs, a Coder and service desk agents.
CogniRunner is a Forge app for Jira Cloud (app id ari:cloud:ecosystem::app/36415848-6868-4697-9554-3c3ad87b8da9, Node.js 22 runtime, sold through the Atlassian Marketplace). Jira's native workflow rules check structure — a field is set, a value equals X. CogniRunner adds rules that read meaning: you write the check in plain English ("the description must include steps to reproduce, expected behavior, and actual behavior") and an AI model evaluates the actual field content on every transition. It ships as four workflow extensions — a validator, a condition, and two post-functions — plus an admin app with 14 tabs, an issue sidebar, the Coder (an issue panel and a full-screen workspace) and Virtual Administrator agents, and works in both company-managed and team-managed projects (projectTypes in manifest.yml). Beyond transitions, listeners react to Jira and git events and scheduled jobs run on a cron.
Every validator can run in one of two lanes. The AI lane sends the field content to the AI provider you configure and can run an agentic loop — the model may call a JQL search tool mid-validation to look for duplicates or related issues. The field read, any MCP tools and every AI round share ONE 20-second budget counted from the moment the validator starts (VALIDATOR_AI_DEADLINE_MS = SYNC_AI_DEADLINE_MS = 20000, src/shared/ai-seam-budgets.js). The premade lane is a catalog of checks (required field, regex, text length, date bounds, sub-tasks resolved, git and Confluence checks…) that runs inside the app with no AI call: zero token cost, instant. Conditions never involve AI — Jira evaluates them itself as a sandboxed Jira expression with no network access, so an AI condition is structurally impossible (the manifest describes the jira:workflowCondition module as "Shows the transition only when a field check passes (no AI; checks run inside Jira).").
CogniRunner ships with no embedded API key. The Settings provider picker has eleven options: Anthropic, OpenAI, Google Gemini, Azure OpenAI, AWS Bedrock, OpenRouter, Ollama, Goose Swarm, any OpenAI-compatible server, a self-hosted LM Studio server (with LM Link), or the zero-key Atlassian (Forge LLM) — Claude models served inside the Atlassian platform via @forge/llm, with no key, and the model call never leaves the platform. The provider labels here are the exact dropdown entries (PROVIDER_LABELS, productNames.js).
executePostFunction always returns { result: true }. The exact messages for every failure path are catalogued in "When the AI cannot answer" below.The editor's "Rule kind" toggle switches a validator between a plain-English AI prompt and a deterministic catalog check; conditions skip the toggle entirely and always open in the premade form.
When you configure a validator, the first choice is the Rule kind toggle: "AI prompt — Describe the check in words; AI evaluates each transition" or "Premade rule — Pick a ready-made check, no AI, instant, zero cost" (exact button copy from config-ui App.js). Conditions never show the toggle — the editor forces ruleKind = "premade" for them, because Jira evaluates conditions as an expression and an AI condition can never exist. The toggle is hidden rather than shown-and-disabled, deliberately: the app does not offer something that cannot work.
| Catalog key | Label in the picker |
|---|---|
field-required | Field is required |
field-changed | Field must be changed |
field-comparison | Field compares to a value (equals / does not equal / greater / at least / less / at most / contains) |
field-regex | Field matches a pattern |
allowed-values | Field is one of… |
text-length | Text length is within bounds |
date-relative | Date is in the future / within N days |
sub-tasks-resolved | All sub-tasks must be resolved |
attachment-required | An attachment is required |
comment-required | A comment is required |
field-cardinality | Field value count is within bounds |
git-build-passed | Git: the pull request's build passed |
git-pr-approved | Git: the pull request is approved |
git-pr-comments-resolved | Git: the pull request's comments are resolved |
git-pr-merged | Git: the pull request is merged |
confluence-page-exists | Confluence: a page for this issue exists |
A premade condition is compiled into the Jira expression declared in manifest.yml, so Jira hides the transition without ever calling the app and without any AI. Exactly fourteen types are expression-backed (EXPRESSION_BACKED_CONDITIONS): issue-type-is, issue-is-resolved, resolution-is, priority-is, parent-status-is, current-user-is-assignee, current-user-is-reporter; three field checks — field-has-value, field-empty, field-equals — for CUSTOM fields only, with the comparison strategy chosen per live-probed field kind (CONDITION_FIELD_KINDS: text, URL, date and number fields compare as values; select/radio compare their option; multi-value kinds support has/empty only); three git checks — the pull request is merged, is approved, the build has not failed — and one Confluence check, a page is linked to this issue. The git and Confluence checks read a property CogniRunner keeps on the issue, and each evaluates to true when that property is missing, so a condition hides a transition only on a known-negative state. The git checks need an enabled git listener on the repository subscribed to their events. The catalog lists 20 condition entries; the six Jira's sandbox cannot evaluate (attachments, sub-tasks, linked issues, a user field, group or project role) are shown greyed out.
The Semantic Post Function is the AI-at-runtime one: after a transition, the model evaluates a condition you describe and modifies a target field — the editor tags it "AI cost per run". The Static Post Function inverts the cost: AI writes sandboxed JavaScript for each step at CONFIGURATION time, and at runtime the generated code executes with no AI call at all — tagged "No AI cost at runtime". A static rule chains up to 50 steps (maxSteps in src/shared/rule-portability.js), each with a 22-second execution budget (PF_BUDGET_MS = 22000); since 1.26.1 every code step runs in its own isolated engine, stopped with a message naming the limit if it overruns its time, uses more than 64 MB or recurses too deeply. Writing or changing code steps needs a CogniRunner admin (1.23.0). Besides these two, the semantic family has flavors that comment, create sub-tasks, link related issues, generate a PDF, Word or PowerPoint document, research and save, write or comment on a Confluence page, or hand the transition to the Coder; Add Comment, Create Sub-task, Link Related Issues and Generate Document run in the background a few seconds after the transition (1.26.7).
Fifteen object kinds, each with its own storage key family in Forge KVS — knowing them makes every later chapter concrete.
config_registry KVS key (capped at 500 rows, REGISTRY_MAX_ROWS in src/shared/registry-limits.js) so the admin panel can list, disable and audit rules. New rules get a per-instance id ending ::i-<6 alnum> so two same-type rules on one transition never share an identity.ai-text-field-validator module. Runs in the app backend as validate(args) and returns { result: boolean, errorMessage?: string } — result: false blocks the transition and Jira shows the message. Both lanes (AI prompt and premade) run here.ai-text-field-condition module. NOT executed by the app: Jira evaluates the manifest's Jira expression directly. Anything the expression does not recognise — including every pre-release saved config — deliberately evaluates to true, because an erroring condition would hide the transition for everyone.ai-semantic-post-function and ai-static-post-function modules. Always return { result: true } — they act after the transition and can never block it. Static-rule step code larger than 24,576 bytes is offloaded from the workflow config to its own content-addressed KVS key pf_code:{id}:{hash} (the workflow editor caps an embedded rule config at 32,768 bytes).ruleKind: "premade" plus a catalog ruleType. Runs deterministically — the validator executor lives in src/premade-rules.js, the condition variant in the manifest expression. Zero AI cost, and it short-circuits before any provider/credential work.COGNIRUNNER_AI_PROVIDER names the provider; each provider keeps its own COGNIRUNNER_KEY_{provider}, COGNIRUNNER_MODEL_{provider} and COGNIRUNNER_BASEURL_{provider} slots, so switching providers never loses the others' settings.log_entry:<inverted-timestamp>_<random> — per-entry keys so concurrent writers (validator + post-function on the same transition) can never lose entries to a read-modify-write race. 30-day TTL, pruned to the newest 50 (MAX_LOGS). Since 1.26.15 every rule also keeps its own last 20 runs (RULE_LOG_MAX), so a busy rule can no longer push a quiet rule's history out of view. Premade runs log metadata only, never field values.skill_repo:{id} with a skill_repo_index; capped at 100 custom skills, ≤45,000 chars serialized each (instructions ≤24,000, examples ≤16,000). Builtins are exempt from the cap.pf_memories array — cap 200 items and about 230 KB serialized (MAX_MEMORIES, MEMORY_MAX_SERIALIZED_BYTES), with near-duplicates (Jaccard ≥ 0.85) reinforced instead of duplicated. Settings live in COGNIRUNNER_MEMORY_SETTINGS; defaults are { autoCapture: false, injection: true, runtimeInjection: false } — capture and runtime injection are opt-in.doc_repo:{id} with doc_repo_index; the index is capped at 50 documents (MAX_DOCS), of which 10 are shipped builtins (src/shared/builtin-docs.js) that are exempt from eviction. Deleting a builtin flips it to disabled — reseeding never resurrects it.listener:{id} with a listener_index.job:{id} with a job_index.coder_thread:{issue}:{thread}, listed per issue in coder_sessions:{issue}). Staged edits never reach the repository until a person confirms the commit or pull request.git_conn_index, git_conn:{id}). Its credential is write-only: checked before it is stored and never shown again.Four workflow extensions in the workflow editor's rule pickers, a global page under Apps, an admin settings page, a read-only sidebar on every issue, and the Coder as an issue panel and a full-screen project page.
| Module | Key | Name shown in Jira | Manifest description |
|---|---|---|---|
jira:workflowValidator | ai-text-field-validator | CogniRunner Field Validator | "Validates a text field value against a custom AI prompt on workflow transition." |
jira:workflowCondition | ai-text-field-condition | CogniRunner Field Condition | "Shows the transition only when a field check passes (no AI; checks run inside Jira)." |
jira:workflowPostFunction | ai-semantic-post-function | CogniRunner Semantic Post Function | "AI evaluates a condition and modifies a target field after workflow transition." |
jira:workflowPostFunction | ai-static-post-function | CogniRunner Static Post Function | "Chains multiple operations with AI-generated code after workflow transition." |
| Module | Key | Title | What you get |
|---|---|---|---|
jira:globalPage | cognirunner-global-page | CogniRunner | The main app under Jira's Apps menu. Fourteen tabs (src/shared/admin-tabs.js): Rules, Listeners, Scheduled Jobs, Agents, Execution Logs, Documentation, Skills, Memories, Knowledge, MCP, Permissions, Settings, Audit log and Your setup. MCP, Permissions, Settings and Audit log are admin-only; each role sees the tabs it can use, and a person with no grant sees only Your setup. |
jira:adminPage | cognirunner-admin-settings | CogniRunner Settings | The SAME app served from Jira's admin settings area — guaranteed reachable for site admins even if the Apps menu entry is hidden from them. |
jira:adminPage (useAsConfig, useAsGetStarted) | cognirunner-configure | CogniRunner | The SAME app again, opened by the Configure and Get started buttons on CogniRunner's row in Jira's Manage apps page (1.28.0). Jira does not list it in the settings sidebar, so the page above stays there. |
jira:issueContext | cognirunner-issue-glance | CogniRunner | A read-only right-rail panel on the issue view showing recent rule activity for that issue (resolver getIssueActivity, gated by an as-user view check), the Coder sessions on it, and, for CogniRunner editors and admins, what agents did there and what waits for a person. |
jira:issuePanel | coder-panel | CogniRunner Coder | The Coder inside the issue: pick a repository, ask in Plan mode (reads only, writes its plan into the issue) or Agent mode (stages edits as a diff), and confirm each commit or pull request. |
jira:projectPage | cognirunner-coder-workspace | Coder workspace | The full-screen Coder: Files, Conversation and Changes side by side, with your own and shared sessions. |
All four workflow extensions share one configuration UI (config-ui-resource for create/edit) and one read-only summary (config-view-resource for the workflow editor's view mode). Company-managed classic editor: open the workflow, select a transition, then the Validators / Conditions / Post Functions tab → Add; the CogniRunner entries appear under the names above. The new workflow editor and team-managed projects reach the same picker through the transition's rules panel.
Two queue consumers carry every long-running job, the llm module enables the zero-key Forge LLM provider, triggers deliver Jira events to listeners, and web triggers serve the Rules REST API, git webhooks and attachments.
| Module | Key | Budget / gating | Purpose |
|---|---|---|---|
consumer | async-ai-consumer | queue async-ai-queue, timeoutSeconds: 120 | Runs the background task types registered in src/async-handler.js: code generation and fixes, AI reviews, skill and memory distillation, background post-functions, listener runs, scheduled job runs and pull-request reviews. |
consumer | long-consumer | queue long-queue, timeoutSeconds: 900 | Every Coder turn and every Virtual Administrator item runs here, with up to 15 minutes per segment; a long Coder turn carries on in a new segment by itself. |
trigger / scheduledTrigger | listener-*-events, scheduled-jobs-tick, privacy-report-daily | one handler for all events | Delivers the 68 Jira, Jira Software and Jira Service Management events to the enabled listeners, and ticks the scheduled jobs; once a day it runs the personal data report (licence-exempt). |
llm | cogni-llm | model: claude | Enables the Atlassian (Forge LLM) provider — Claude served inside the platform via @forge/llm. No key, and no egress for the model call. The Standard edition runs Claude Haiku; the Coder edition adds Claude Sonnet 5 and Opus 5 (FORGE_LLM_MODELS, src/shared/edition.js), from a monthly allowance shown in Settings. |
webtrigger | harness-test-state | Gated by HARNESS_SECRET; returns 404 in production | Development test-harness endpoint only. |
webtrigger | attachment-bridge | One-shot capability token (URL token + Authorization bearer) | Serves a single Jira attachment as base64 JSON so a self-hosted LM Studio model can READ attachments through the doc-reader tool. |
webtrigger | attachment-upload | Same one-shot token model | The write side: accepts a generated document envelope and attaches it to the bound issue via api.asApp(). |
webtrigger | rules-api | Bearer API keys minted in Settings; each key follows its creator's current role and reach | The Rules REST API: create, list and run listeners, jobs and Virtual Administrators, and dry-run a validator or AI post-function against an issue, from CI or scripts. |
webtrigger | git-webhook | Per-repository signature, checked before anything is queued | Turns GitHub or Bitbucket repository events into listener runs. |
Validators and conditions ALWAYS run synchronously inside the transition — they never queue. The queues carry configuration-time AI work (code generation, code fixing, rule reviews, skill distillation), listener and job runs, the Add Comment, Create Sub-task, Link Related Issues and Generate Document post-functions (which run a few seconds after the transition), and AI work on LM Studio: self-hosted models are too slow for the 25-second sync resolver cap, so those resolvers detect provider === "lmstudio" and queue instead, with the frontends polling. The admin panel says it next to its jobs list: "Validators & conditions run synchronously and don't queue; finished jobs move to “Recently completed” under Execution Logs."
async_task:{id}) are deleted the moment a frontend collects them. Finished jobs surface under "Recently completed" in Execution Logs and clear themselves after ~20 minutes.Forty-six scopes in manifest.yml — reads for validation and pickers, writes for post-function actions, Jira and project administration for the rule registry and the field picker, Confluence for the Confluence rules, the reads and writes behind the Atlassian calls an admin allows an agent, and reporting personal data to Atlassian.
| Scope | Why the app needs it |
|---|---|
read:jira-work | Reading issues and field values at validation time (when modifiedFields lacks the field, the value is fetched over REST), the agentic JQL search tool, attachment reads, and the issue glance. |
write:jira-work | Post-function writes: updating fields, adding comments, creating sub-tasks and links, worklogs, transitions — every mutating sandbox API method. |
read:jira-user | User lookups for pickers and sandbox methods like setAssignee / addWatcher. |
read:project:jira | Project lists for pickers and per-project rule context. |
storage:app | The Forge KVS — where every object in the glossary above lives. |
manage:jira-configuration | The site-admin check: Jira's ADMINISTER permission probe, with membership of jira-administrators, site-admins or system-administrators read through GET /rest/api/3/group/member when the probe cannot answer. Since 1.29.0 the workflow calls rely on it too: reading published workflows (/rest/api/3/workflows/search) to discover which transitions actually carry CogniRunner rules — the Rules tab's registry scan and orphan cleanup — and POST /rest/api/3/workflows/update, which propagates a rule's disabled flag into the workflow's own embedded condition config (Jira cannot read app storage when evaluating the expression) and provisions rules over REST. It also covers the issue-type screen scheme lookups (issuetypescreenscheme/project and /mapping) behind the "Field to Validate" picker. |
manage:jira-project | Sandbox methods that create project-admin objects: createVersion (POST /rest/api/3/version) and createComponent (POST /rest/api/3/component). Since 1.29.0 it also covers the rest of the "Field to Validate" picker's path — screen scheme → screen → tabs → fields — so the picker lists the fields that actually exist on the transition's screens. |
write:sprint:jira-software, write:board-scope:jira-software, write:issue:jira-software | The agile sandbox methods: moveToSprint / moveToBacklog and rankIssue. |
read:app-data:jira, write:app-data:jira | Added in 1.27.0: a private note of where the app's backup of your setup is kept, so a reinstall can find it. |
read:space:confluence, read:page:confluence, search:confluence, write:page:confluence, read:comment:confluence, write:comment:confluence | The Confluence validator, condition and post-functions, and the Confluence actions agents may take, each bounded to the spaces you allow (CogniRunner must also be installed on Confluence). |
report:personal-data | Added in 1.29.0: reporting the Atlassian account ids the app stores to Atlassian's personal data reporting API, so the app can erase the accounts Atlassian reports as closed (see "Environment & data flow"). |
| Jira Software, Jira Service Management, Assets and Confluence page-tree scopes (boards, sprints, epics, permissions, service desk requests and customers, knowledge base, Assets objects, Confluence attachments, labels, folders, and deleting pages and comments) | Added in 1.26.0, used only by the Atlassian REST operations an admin picks for an agent. Deletes and configuration changes through them never run without a Jira administrator's approval. |
report:personal-data and removed six scopes the administration scopes already cover (read:workflow:jira, write:workflow:jira, read:issue-type-screen-scheme:jira, read:screen-scheme:jira, read:screen-tab:jira, read:screenable-field:jira), so nothing stops working.Workflow editor → add a validator → pick CogniRunner Field Validator → write one plain-English sentence → test against a real issue → publish.
claude-haiku-4-5-20251001) — paste your API key, choose a model. Or pick "Atlassian (Forge LLM)" and skip the key entirely, or point it at your own LM Studio, Ollama or OpenAI-compatible server.AI Validation failed: <the model's reason>.Every degraded path allows the transition and says so in the log — the exact strings, so you can recognise each one.
A workflow rule that fails closed on an outage locks a whole team out of their board. CogniRunner's law is the opposite: a rule only blocks a transition on a genuine isValid: false verdict from a completed evaluation (or a reply so malformed that no verdict can be recovered from it). Every infrastructure failure degrades to ALLOW, with a distinct reason recorded in the execution log.
| Situation | What happens | Exact reason string |
|---|---|---|
| License inactive | Transition allowed, AI skipped entirely | (logged) "License inactive — skipping AI validation (fail open)" |
| Rule disabled in the admin panel | Transition allowed; matching is by rule identity, never by field alone | (logged) "Rule … is disabled in KVS — skipping AI validation" |
| No provider API key | Transition allowed | "AI validation is not configured (no provider API key). Transition allowed (fail-open). Set the provider API key in CogniRunner settings." |
| Provider 429 / 408 / 5xx, after up to three retries | Transition allowed, marked transient | "AI service temporarily unavailable (<status>). Transition allowed (fail-open)." |
| Other provider error | Transition allowed | "AI service error (<status>). Transition allowed (fail-open). Check the AI provider/key in CogniRunner settings." |
| The validator's 20 s budget runs out (counted from when it starts) | Transition allowed — bounded below Forge's hard 25 s kill so the return is graceful | "AI validation timed out. Transition allowed (fail-open)." |
| The AI reply is empty, withheld by a content filter, or cut off at the output limit | Transition allowed | "AI returned an empty reply (no verdict). Transition allowed (fail-open)." / "AI reply was cut off at the output limit … before it gave a verdict. Transition allowed (fail-open)." |
| Agentic loop runs out of tool-call rounds | Transition allowed | "Validation reached maximum tool-call rounds without a final answer. Transition allowed (fail-open)." |
| Jira throttles the field/attachment read | Transition allowed | "Field could not be read (Jira throttled the request). Transition allowed (fail-open)." / "Attachments could not be read (Jira throttled the request). Transition allowed (fail-open)." |
| CogniRunner's own storage is busy and the rule or provider settings cannot be read | Transition allowed; the rule is never run as if it were switched on | "… so this rule could not be checked. The transition was allowed (fail-open). The rule and the API key are fine; this clears within a minute." |
| The monthly allowance for the Atlassian Forge LLM is spent | Transition allowed, with the reason stated, until the allowance resets | (the reason names when the allowance resets) |
| A premade format pattern would take too long to run | Transition allowed | (the pattern fails open; 1.26.15) |
Conditions carry the same philosophy in Jira's own engine: the manifest expression's default branch is TRUE, so an unrecognised or unparsed config shows the transition instead of hiding it for everyone. Post-functions can never block by construction — executePostFunction always returns { result: true }, and every skip writes a postfunction-skipped log entry so silence is still visible.
Workflow rules follow Jira's own editor permissions; inside the app a person or a whole Jira group holds Viewer, Editor or Admin over their own rules or everyone's, and a switch decides whether Jira site admins are automatically CogniRunner admins.
Attaching a rule to a workflow happens in Jira's workflow editor, so Jira's rules apply: Administer Jira for company-managed workflows, project administrators for team-managed projects (both projectTypes are declared). CogniRunner adds its own layer for the admin panel, rebuilt in 1.20: on the admin-only Permissions tab you give a person or a whole Jira group Viewer, Editor or Admin access over everyone's rules or only their own, change it or remove it. Every grant is checked against Jira before it is saved, so an inactive, unknown or app account cannot be added, and the tab shows the latest 20 permission changes. The one model lives in src/shared/permissions.js, and the tab strip is derived from the same table the backend enforces.
| Role | Tabs | What it can change |
|---|---|---|
| No grant | Your setup only, when the Coder is available on the site; otherwise nothing | Their own git session, the deploy secrets note for a Forge app pipeline, and Coder preferences |
| Viewer | Rules, Listeners, Scheduled Jobs, Execution Logs, Documentation, Skills, Memories, Knowledge | Nothing: no add, edit or delete controls are shown |
| Editor (own rules) | The viewer tabs plus Agents (read-only) and Your setup | Create and change their own rules, listeners, jobs, docs and skills; add and change the shared memories; use the Coder |
| Editor (everyone's rules) | Same tabs | The same, on every rule |
| Admin | All 14 tabs, including MCP, Permissions, Settings and Audit log | Everything, including provider keys, API tokens, agents, and writing code steps in listeners, jobs and static post-functions |
A switch on the Permissions tab decides whether Jira site administrators are automatically CogniRunner admins (on by default). A person's explicit grant always wins, which is how a site admin is given a narrower role inside CogniRunner. The app refuses to remove or restrict the last working admin, asking Jira at that moment who would still be an admin after the change, and with the switch off and no admin left, a Jira site administrator is let in as admin so a site can never lock itself out.
Everything is Forge KVS inside your own Atlassian site — no external database. The key families, their caps, and their TTLs.
| Key(s) | Holds | Bounds |
|---|---|---|
config_registry | The rule registry (one row per configured rule) | 500 rows; rows are slimmed on every write |
pf_code:{id}:{hash} | Offloaded static-PF step code, content-addressed and immutable | Written when serialized steps exceed 24,576 bytes; ≤220 KiB per bundle |
log_entry:<inverted-ts>_<rand> | Execution history, one entry per run | Newest 50 kept (MAX_LOGS); 30-day TTL; probabilistic prune on ~10% of writes. Each rule also keeps its own last 20 runs (RULE_LOG_MAX) |
doc_repo_index, doc_repo:{id}, doc_repo_seed_meta | Documentation library | 50 docs; 10 builtins eviction-exempt |
skill_repo_index, skill_repo:{id}, skill_repo_seed_meta | Skills | 100 custom; ≤45,000 chars serialized each |
pf_memories | Learned memories (single array) | 200 items / about 230 KB serialized; each ≤400 chars |
COGNIRUNNER_AI_PROVIDER, COGNIRUNNER_KEY_{p}, COGNIRUNNER_MODEL_{p}, COGNIRUNNER_AGENT_MODEL_{p}, COGNIRUNNER_CODER_MODEL_{p}, COGNIRUNNER_BASEURL_{p} | Provider connection (BYOK slots, with a model, an agent model and a Coder model per provider); the key slot is a secret row (setSecret) since 1.28.0 | Admin panel only — never environment variables |
COGNIRUNNER_MEMORY_SETTINGS | Memory feature toggles | Defaults { autoCapture: false, injection: true, runtimeInjection: false } |
COGNIRUNNER_USAGE | The AI usage meter (calls + tokens, per provider, month/day buckets) | Provider set clamped to the known provider ids (anything else counts as other) so it can never grow unbounded |
async_task:{id}, pf_exec:{id} | Async job status and post-function execution records | TTL-bound (2 h active / 20 min terminal); polled rows deleted on collection |
app_admins, app_access | The app's people grants, and the site-admin switch with the group grants | A limit on how many people and groups can hold a grant, stated before anything is saved |
listener_index + listener:{id}, job_index + job:{id} | Listeners and scheduled jobs | — |
coder_thread:{issue}:{thread}, coder_sessions:{issue}, coder_stage:… | Coder conversations, the sessions index per issue, staged files | Deleting a session removes its conversation, steps and uncommitted files |
git_conn_index, git_conn:{id}, git_conn_secret:{id} | Git connections and their write-only credentials (the git_conn_secret row is kept with setSecret) | — |
Provider API keys deserve a plain statement: since 1.28.0 they are stored in Forge's encrypted secret storage on your site (kvs.setSecret, as are git tokens, webhook secrets and MCP credentials; a key saved earlier moves there the first time it is used), entered only through the admin panel, and sent only to the provider they belong to. The usage meter is an honest best-effort UNDER-count — it reads and re-writes a single key without compare-and-set, so concurrent runs can lose increments; a soft monthly-call-ceiling helper exists in the meter module but nothing calls it. The limits that are enforced live elsewhere: the Atlassian Forge LLM's monthly allowance, each agent's daily AI token budget, and the AI limits on each REST API key (20 every 10 minutes and 200 a day). API keys and tokens are never included in the backup of your setup.
Cloud BYOK providers receive issue content; a server you run yourself receives it only on your own hardware; the Forge LLM's model call never leaves Atlassian. The hosted providers' hosts are named in the manifest.
When an AI rule runs, the prompt contains the validated field's value, the issue context the rule needs, any doc-library documents attached to the rule, JQL search results when the search tool fires, and — if enabled — learned memories. All of it is injected inside guarded <<<MARKER … MARKER>>> fences and defanged, but fencing is a prompt-injection defence, not privacy: whatever is in the prompt reaches the model's operator. The browser side of the app (the Custom UI pages) may reach only the hosted providers listed in the manifest. Since 1.10 the BACKEND may reach any https host, because a self-hosted OpenAI-compatible or Ollama server lives on a host only you know; a project's AI provider can only use the address an admin set in Settings, and its key is never sent anywhere else (1.23.0).
| Provider (dropdown label) | Endpoint | Issue content leaves Atlassian? | Default model |
|---|---|---|---|
| Anthropic | api.anthropic.com (/v1/messages, x-api-key) | Yes — to Anthropic, under your key and their data terms | claude-haiku-4-5-20251001 |
| OpenAI | api.openai.com/v1/chat/completions | Yes — to OpenAI | gpt-5.4-mini |
| Azure OpenAI | {resource}.openai.azure.com/openai/v1 (api-key header; model = your deployment name) | Yes — to your Azure tenant. Same code path as OpenAI, but end-to-end behavior is honestly flagged as mostly untested (no live Azure deployment in the harness) | gpt-5.4-mini |
| Google Gemini | generativelanguage.googleapis.com (Gemini's OpenAI-compatible endpoint) | Yes — to Google | gemini-3.8-flash |
| OpenRouter | openrouter.ai/api/v1 (plus HTTP-Referer / X-Title attribution headers) | Yes — to OpenRouter AND the upstream vendor of whichever model you pick from its 300+ catalogue | openai/gpt-5.4-mini |
| AWS Bedrock | bedrock-runtime.<region>.amazonaws.com (Converse API, Bedrock API key as plain bearer — no SigV4) | Yes — to your AWS account in your chosen region | eu.anthropic.claude-sonnet-4-6 (a cross-region inference-profile id; admins pick their own) |
| Ollama | Ollama Cloud (ollama.com/v1) with an API key, or your own Ollama server over https | Yes to Ollama Cloud; on your own server, only to hardware you control | None — you pick from what is pulled |
| LM Studio | Your own machine over https, for example a Tailscale Funnel URL (https://your-machine.tailXXXX.ts.net) | Leaves Atlassian, but ONLY to hardware you control — no third-party AI vendor is involved | None — you pick from the models loaded on your server |
| OpenAI-compatible server | Any server that speaks /v1/chat/completions (vLLM, llama.cpp, LocalAI, a corporate gateway), over https | Only to the server you name | None — you pick from what it lists |
| Goose Swarm | Your Goose Swarm node over https, with its server secret as the token | Only to your node, and to whatever providers that node is configured to use | None — you pick from what the node lists |
| Atlassian (Forge LLM) | In-platform via @forge/llm — the model call has no network egress | Not for the model call. Tools you turn on (MCP servers, web search, git) still reach their own services | claude-haiku-4-5-20251001 (Standard runs Haiku; the Coder edition adds Sonnet 5 and Opus 5; text-only, no image/file input) |
Further manifest hosts complete the honest picture: mcp.context7.com (a hosted documentation MCP), *.ts.net for self-hosted MCP servers, and, backend only, api.github.com, api.bitbucket.org and bitbucket.org for the git connections the Coder and the git rules use. The Bedrock wildcard *.amazonaws.com covers both the runtime and control-plane hosts across regions. If you configure no cloud provider — Forge LLM or a server you run yourself — no issue content reaches a third-party AI vendor; that is the accurate version of a "no egress" claim for this app, and it is provider-dependent, not absolute.
COGNIRUNNER_USAGE (calls, prompt/completion tokens, per provider, month and day buckets). On the Atlassian Forge LLM the edition's monthly allowance is shown with a meter that warns at 80 percent; when it is spent, AI rules pause until it resets. Settings, Maintenance also shows CogniRunner's Jira API use hour by hour (1.21.0).Install from the Marketplace, point it at a transition, an event or a schedule, and write your first rule in plain English, or open the Coder on an issue. Or have us build the rules for your team and hand them over.