As soon as the team decides to “add AI review,” it inevitably begins discussing not one integration but the structure of a production process:
AgentWhich model or composition of agents finds real defects most effectively?
HarnessWhich harness, system prompt, and set of skills should be used for review?
ContextShould it receive only the diff, the whole module, issue history, or architectural conventions—and how much of each?
AccessDoes the agent need tests, builds, Git history, and project tools, and what must remain read-only?
Jira round tripHow does a finding reach the issue, how can someone ask a follow-up, and how does the dialogue continue with the same executor?
MeasurementWhich findings are useful, where are the noise and misses, how much does a run cost, and which version is actually better?
Local shortcut
Python → Codex → Jira comment
This script demonstrates the idea quickly, but immediately hard-codes one model, one harness, one prompt, one amount of context, and one response path. Every experiment becomes a change to integration code; versions cannot be compared and the choice cannot be justified. It is legacy from the first minute of its existence.
Shared system
Issue → Reviewer.Agent → execution → artifacts → Jira
In Multica, the agent, harness, skills, access, context policy, and return path become configuration and system entities. Every attempt retains a version, trace, and metrics: alternatives can be compared, and the conversation with the executor can continue within the task context.