This is a Developer Preview . It is complete enough to run real work under oversight, but some controls and
installation steps are not yet production grade. Each item below is planned to be fixed before production .
Where an item matters for a page, that page repeats it in red.
Changes to items written by people always wait for approval. Items made by agents (marked AI
generated ) can be changed directly by any hired agent, not only by the one that made them.
Production: an agent changes only its own AI items; changes to another agent’s items are held.
Editing a paragraph of a document, comments, links between items, moving items into documents and comments on
documents are not held for approval. They are limited only by the agent’s Polarion permissions.
Production: these writes follow the same rules as field changes on human-written items.
Approve, deny and answer actions check that the person can access the project. They do not check that the
person is the agent’s supervisor . Workaround: restrict who can edit tasks with Polarion permissions.
Production: decisions are limited to the supervisor (and named deputies).
Storing credentials, discovering MCP servers and controlling sandboxes on the Agency and Administration
pages require only read access to the Agent Pool project. Workaround: give access to the Agent Pool project to administrators only.
Production: these actions require an administrator role in the Agent Pool.
Sandbox internet access is limited to approved sites and to reading (GET). An agent could still put data into
the URL of a request. Workaround: approve only sites you trust. Production: URL inspection and logging
of query strings.
Built-in runs stop after the model call that reaches the budget, so the last call can go a few cents over.
Codex runs have no in-run cap at all; their budget is checked before each run.
Production: a run stops before a call that would cross the budget, for every harness.
An engagement with an empty budget or a budget of 0 is treated as unlimited. The hire wizard always sets a
budget, but engagements edited directly in Polarion can lose it. Production: no budget means no work.
PocketBase keeps held calls (with their arguments and results) and full chat histories without automatic
clean-up. Production: configurable retention.
Run transcripts are attachments on Agent Run items and follow the project’s read permissions.
Production: separate permission for transcripts.
“Always allow” rules live in a JSON field on the engagement. They are visible and revocable in the agent’s ⚙ menu,
but not readable on the engagement form itself. Production: a readable Standing approvals table on the
engagement.
Agentic setup configures the Agent Pool and every AI-enabled project from the browser, but the Agency page
has to be reachable first: in a new pool project you add one line (<applicationView id="agentic.agency"/>) to
the navigation in Polarion’s administration, for the administrator hat (see
Installation ). Agency then adds the
Administration page itself, from a banner, and Setup does the rest.
Production: the app adds its first navigation entry itself.
The app’s pages exist only inside projects, so the Agent Pool and the AI-enabled projects are managed from
Administration → Setup in the pool project, not from Polarion’s global administration.
Production: a server-wide Agentic administration page.
The Agent Pool is owned entirely by the platform: Agentic setup removes work items and work item types the pool
does not use, after a confirmation, and they cannot be restored from the app. Workaround: only ever use an
empty project as the pool. Production: setup refuses a project that holds work of other types.
The sandbox egress image names the model host in its build file (AGENTIC_WRITE_HOSTS). Workaround: set it
for your environment before building the image (see Sandboxes ). Production: the image
reads your configuration.
The command-line preflight helper contains environment-specific settings, and the preflight’s project checks
are tuned for example projects. Workaround: call the runner’s GET /preflight endpoint and use the
platform checks (models, Polarion, tokens, PocketBase, MCP servers, sandboxes). Production: project checks
from configuration.
Polarion has no API for personal access tokens, so each agent’s token is created by an administrator on the
agent user’s token page and pasted in. Administration → Credentials turns this into a checklist per agent
(user exists → token set → signs in) with the create-user button and the link to the token page, but the token
itself stays a copy-and-paste step, and the licence is assigned in Polarion. This is by design of Polarion and
will remain so.
The runner does not know when a stored token (an agent’s Polarion token or the model key) expires. It only finds
out when the token stops working. Workaround: Test in Administration → Credentials and the preflight check show a
token that no longer signs in; replace it there. Production: expiry dates are tracked and a warning appears
before a token runs out.
These are not bugs and stay true in production. Plan for them.
Prompt injection. Text in work items, documents, tool results and web pages reaches the model. The controls
limit what an agent can do , not what it believes .Costs are estimates , computed from token usage and a price table.Agents can be wrong. That is why results, important changes and memories wait for a person. 