What's New in CogniRunner: Local AI, Zero-Key Models & Actions That Write Back
Key takeaways
- Run AI on your own hardware with LM Studio — the first Jira app to do it — or zero-key inside Atlassian with the new Forge LLM provider.
- Declarative AI actions go beyond validation: draft comments, create sub-tasks or linked issues, and generate DOCX/PDF/PPTX — all in plain English.
- Skills, Memories, and a shared documentation library ground every decision in your team's real context.
CogniRunner — the semantic layer for Jira workflows — just got its biggest update yet. If you've used it to block a vague bug report or flag a likely duplicate, the core idea is familiar: write a plain-English prompt, pick a field, and let an AI model judge meaning, not just structure. This release pushes that idea in three directions: where the AI runs, what it can do after it decides, and how well it understands your project.
The CogniRunner admin dashboard
CogniRunner is open source under Apache-2.0. Everything below is in the shipping app on the Atlassian Marketplace — and in the open on GitHub.
Run AI where your data lives
The headline of this update is choice of where inference happens. CogniRunner now spans the full spectrum, from fully local to fully managed:
| Option | What it means | Best for |
|---|---|---|
| LM Studio (local) | Inference and your field data stay on your own hardware. Zero per-token cost. | Maximum privacy, air-gapped or cost-sensitive teams. |
| Atlassian Forge LLM | Zero-key, runs inside Atlassian's platform — no API key, no external egress. | The fastest start; data never leaves Atlassian. |
| BYOK cloud | Bring your own key: OpenAI, Anthropic, Azure OpenAI, OpenRouter, AWS Bedrock. | A specific model, vision support, or your own account. |
CogniRunner is the first Jira app to integrate LM Studio for on-device inference, and among the first to ship the Atlassian Forge LLM provider — AI that runs with no key and no egress, so the app keeps its Runs on Atlassian eligibility. Switching providers never loses your other keys; each is stored per-provider, encrypted at rest.
Multi-provider AI configuration
With LM Studio, field content and attachments never leave your machines. With the Forge LLM provider, they never leave Atlassian's cloud. Privacy is now a configuration choice, not a compromise.
From validation to action
Validators gate a transition; the new declarative AI actions let CogniRunner act on one. After a transition, you can now have the AI:
Draft and post a comment — a summary, a triage note, a status update.
Create a sub-task or linked issue — spin off follow-up work automatically.
Generate and attach a document — a DOCX, PDF, or PPTX, built from the issue's own content.
All of it is configured in plain English — no code required. Under the hood, the same engine powers CogniRunner's static post-functions: the AI writes the JavaScript once at setup, then it runs on every future transition at zero AI cost, chaining up to 50 sandboxed steps.
Declarative actions and the static function builder
Use semantic post-functions when the output should change per issue (a summary, a release note), and static ones for deterministic, high-volume work (creating standard sub-tasks) where you don't want a model call on every transition.
Smarter context: Skills, Memories & the docs library
A model is only as good as what it knows about your project. This update deepens grounding three ways:
Documentation library — upload API specs, JSON schemas, or business rules once, then attach them to any rule so the AI validates and generates against your standards.
Skills — reusable, named capabilities you can drop into rules instead of re-writing prompts.
Memories — instance-specific context the AI learns and carries forward.
Optional MCP integrations (context7 for live SDK docs, web-search, document tooling) extend that reach further — CogniRunner acts as the middle layer and runs the tool calls, so your AI provider never sees the integration URLs.
Agentic by default — the AI searches Jira for you
When a rule needs context beyond the field itself — "is this a duplicate?" — CogniRunner goes agentic: the AI autonomously builds and runs JQL against the issue's own project, over multiple rounds, before deciding. Every query, every round, and the final reasoning are recorded.
Agentic JQL search, fully logged
Agentic search is now confined to the rule's own project and bounded to three rounds within a 22-second budget — and it always fails open. If the model errors or runs out of time, the transition is allowed. A workflow that locks up is worse than one that occasionally misses.
Hardened for production
Beyond features, this release is the result of a long adversarial-review and durability campaign. Among the under-the-hood wins: agentic JQL is project-scoped, the static-function sandbox is tightened, multi-provider dispatch is hardened, and a durability sweeper reaps any killed long-running task so you never see a "stuck" run. It's the same app — just sturdier on a Monday.
Try it
🧪 CogniRunner on the Atlassian Marketplace — install straight into Jira Cloud.
💻 Open source on GitHub — open source under Apache-2.0.
📖 The CogniRunner project page — the full feature tour.
Configuration still takes about 30 seconds: pick a field, write what "good" means in plain English, done. The difference now is that the AI can run on your terms, act on what it finds, and reason with everything your team knows.
Top comments (2)
Separating semantic and static post-functions is a sharp boundary. One thing I’d make configurable per rule is failure posture: a project-scoped JQL timeout on low-risk enrichment can fail open, while an approval or data-mutation rule may need to fail closed or route to manual review. Since every query and round is logged, do you also persist the rule version and provider or model identity so a later incident can reconstruct why a transition was allowed?
@raju_dandigam checked the source rather than guess. On the AI-judgment seam there's no per-rule knob yet — a provider error or timeout during validation always fails open: validators and conditions let the transition through, and a semantic post-function that errors returns decision:SKIP rather than retrying into a manual-review path. (Worth noting elsewhere in the same codebase a fault in the storage or Jira-write layer fails CLOSED instead, so it's a per-seam contract, not one blanket policy — but on this specific validate/act seam it's always open today.) Configurable posture per rule, especially for the approval/mutation case, would be a real improvement.
On persistence: the per-run record written today is an async_job row for operational visibility, not a durable audit log — best-effort, 2h TTL while active, 20 minutes once done, by the source's own comment. It carries ruleId, but that's current identity, not a version snapshot of the prompt/config at run time. Provider and model aren't reliably captured either — on the actual post-function enqueue path, provider is only recorded when it's LM Studio and model is hardcoded null. So no, an incident a couple weeks out can't yet reconstruct which model or which rule version made a given call.