Data model

The platform stores its business data as ordinary Polarion work items. You can query, report on, link and audit them like any other item. A small amount of operational state lives in PocketBase.

Two kinds of projects are involved:

• Agent Pool (one per installation): agents, skills and MCP connections.
• Work projects (any number): engagements, tasks, agent runs, memories and the artifacts agents create.

Everything the platform adds is created by Agentic setup (Administration → Setup) from a versioned configuration that ships with each release; see Installation and Enable a project. All identifiers carry an ai prefix — type ids ai…, link roles ai_…, enumerations ai-… — so they never clash with a customer’s own configuration. Field ids have no prefix.

Agent Pool types

Type id	Name	Represents	Description field holds
aiAgent	Agent	An AI agent that can be hired into projects	The persona / job description, used at the top of the agent’s instructions
aiSkill	Agent Skill	Instructions an agent follows, and the tools they allow	The skill’s instructions
aiConnection	Agent Connection	An MCP server agents may use	Notes for reviewers
aiSettings	Agentic Settings	The platform’s settings for this project (see Agentic settings)	—

Agent fields

Field	Meaning
role	Job title, e.g. “Requirements Engineer”
botUser	The Polarion user the agent acts as
owner	The person responsible for this agent
model	<provider>:<model>, e.g. anthropic:<model>, openai:<model>, google:<model>
harness	builtin (loop in the runner), claude_code or codex (in the task’s sandbox); enumeration ai-agent-harness
avatar	Emoji shown in the views and in the agent’s comment signature
capacity, rateCard, heartbeatMinutes	Informational fields shown in the pool

Skill fields

Field	Meaning
tools	Multi-select of the Polarion tools this skill allows (enumeration ai-agent-tool, see Tools)

Connection fields

Field	Meaning
serverUrl	MCP endpoint (streamable HTTP)
authType	none, bearer (token) or url (the secret is the whole server URL); enumeration ai-connection-auth
credential	Name of the default secret in the runner’s secret store (never the value)
toolPolicy	JSON: per tool its reviewed description, input schema, read/destructive hints and policy read, approve or block
discoveredAt	When the tool list was last read from the server
scoped, scopeArguments, scopeHint, scopeOptions	Scoping: the data is partitioned (repos, projects), which tool arguments carry the scope, what a scope looks like, and how to list real values
serverHeaders	JSON: extra request headers for the server
gitRemote, gitAuth, gitPushBranches	Git over the gateway: remote URL template with {repo}, credential style, branch patterns agents may push to

Work project types

Type id	Name	Represents
aiEngagement	Agent Engagement	One agent hired into this project
aiTask	Agent Task	Work for an agent. A type of its own, so the project’s own Task type and boards stay untouched
aiRun	Agent Run	One run of an agent on a task
aiMemory	Agent Memory	A lesson from the supervisor’s feedback, proposed by an agent and approved by a person
aiSettings	Agentic Settings	The platform’s settings for this project

Agents create artifacts of the project’s own types (requirements, test cases, risks, user stories, …); enabling a project adds nothing to those types except the two provenance fields.

Engagement fields

Field	Meaning
poolAgent	The Agent Pool item that was hired
botUser	The agent’s Polarion user
supervisor	The person who answers questions and approves results
engagementStatus	active, paused or ended; only active engagements get work (enumeration ai-engagement-status)
budget, spent	Budget and cost so far, in USD (see Budgets)
projectInstructions	Extra instructions for this project, part of every prompt
grants	JSON: the connections granted here, each with optional credential, scope, notes for the agent and standing approvals
internetSites	Websites the agent’s sandbox may read, one per line; empty means none

Agent run fields

Field	Meaning
botUser, provider, model	Who ran and on which model
trigger	Why the run started (enumeration ai-run-trigger, see Agent runs)
outcome	done, submitted, asked_human, waiting_approval, failed or budget_stopped (enumeration ai-run-outcome)
tokensIn, tokensOut, costUsd, steps, durationSec	Usage and cost of the run
skillRevisions	The skills in effect for the run
memories	Ids of the project memories in the run’s instructions
ledger	JSON: everything the run read, searched, created, changed, commented, delegated, requested or was blocked from
sandbox	JSON, sandbox runs only: sandbox id, image, harness, commands, web pages read, allowed sites, budget cap

The run’s description holds a readable action log, the artifact table and the table of gateway calls. The full transcript is attached as transcript.html and transcript.json.

Memory fields

Field	Meaning
forAgent	The agents this lesson is for (multi-user field)

Agentic settings

One Agentic Settings item per project, created by Agentic setup:

Field	Meaning
role	pool or work. The runner finds the Agent Pool as the project whose settings item has role pool; the Setup page lists AI-enabled projects by role work
configVersion	The configuration version the project was last set up with. Projects behind the release’s version are marked for upgrade
runnerUrl	Pool only: the Agent Runner address the views call (default /agentic-runner)

Provenance on every type

Two custom fields exist for all work item types:

Field	Meaning
aiGenerated	true on everything an agent creates (artifacts, sub-tasks, memories, agent runs)
authorAgent	The bot user of the agent that produced the item

aiGenerated also decides how changes are handled: agents change AI-made items directly, while changes to items written by people are held for the supervisor’s approval. See Decisions.

Statuses and workflows

Type	Statuses	Actions
aiAgent	draft → available → retired	publish, retire, reinstate, rework (available → draft)
aiSkill	draft → in_review → approved → retired	submit, approve, send back, rework, retire
aiConnection	draft → in_review (“in security review”) → active ↔ disabled	submit, approve, send back, disable, enable, rework
aiMemory	draft (“Proposed”) → active → retired	approve, discard, retire, reinstate

What the statuses mean to the runner:

• Only available agents get work. Draft and retired agents are ignored.
• Only approved skills reach a prompt. Changing a skill means rework and a new review.
• Only active connections can be granted and are served by the gateway.
• Only active memories whose forAgent includes the agent reach its instructions.

Agent Task statuses. The aiTask type has its own status list:

Status	Meaning
open	In the backlog, not started
inprogress	An agent is working on it
waiting_input	The agent asked a question, or a change is held for approval, or the agent stopped twice without finishing
awaiting_approval	The agent submitted its result for review
reopened	Sent back with feedback
done, rejected	Closed by a person

Link roles

erDiagram
  AGENT ||--o{ SKILL : "ai_has_skill"
  AGENT }o--o{ CONNECTION : "ai_uses"
  ENGAGEMENT }o--|| AGENT : "ai_engages"
  TASK }o--|| AGENT : "assigned to"
  AGENT_RUN }o--|| TASK : "ai_run_of"
  ARTIFACT }o--|| TASK : "ai_produced_by"
  ARTIFACT }o--|| AGENT_RUN : "ai_created_by_run"
  MEMORY }o--|| TASK : "ai_learned_from"
  TASK }o--o| TASK : parent

Role	From → to	Created by
ai_has_skill	agent → skill	Pool admin
ai_uses	agent → connection (the agent can work with this system)	Pool admin
ai_engages	engagement → pool agent	Hire wizard
ai_reports_to	engagement → engagement	Available for an org structure; not used by the runner’s logic
ai_produced_by	artifact → task	Agent tools, automatically
ai_run_of	agent run → task	Runner
ai_created_by_run	artifact → agent run	Runner, for every item the run created
ai_modified_by_run	item → agent run	Runner, for every item the run changed
ai_learned_from	memory → task where the feedback was given	propose_memory
parent	sub-task → task	delegate
depends_on	sub-task → sub-task that must be done first	delegate with an “after” task

Agents link artifacts with the project’s own roles, for example refines, verifies, relates_to, depends_on, mitigates, parent and implements.

Hyperlink roles (links to objects in connected systems, set with add_hyperlink):

Role	For
tracked_in	Issue or ticket that tracks the item
implemented_in	Commit, branch or merge request implementing it
verified_by	Pipeline, job or test run that verifies it
ref_ext	Anything else

PocketBase collections

PocketBase holds operational state only. Its API rules are locked: only the runner (as superuser) reads and writes it.

Collection	Purpose
events	Live activity per run (text as it streams, tool calls and results, run started/finished) for the views
runs	A short record per run for the live view (status, usage, the Polarion Agent Run id)
approvals	Held write calls: task, agent, server, tool, exact arguments, the agent’s reason, status, who decided, when, why, and the result
standing_rules	A copy of “always allow” rules per project, agent, connection and tool, restored on a re-hire
task_state	Watcher bookkeeping: the last comment it processed per task
chats	Sidebar chats per project, user and agent: message history, turns, tokens and cost
secrets	Connection credentials, encrypted; the browser can set them but never read them

Note

Approvals in PocketBase hold the exact arguments and results of write calls, and chats hold full conversations. Plan backups and retention for PocketBase like for any system that holds project content.