Skip to main content
A job is a saved instruction: what to do, where to execute it, and when it may run. A trigger is a reason to run it: a manual request, schedule, provider event, or another job’s lifecycle event. A run is one execution of the job, with its own state, prompt, context and output. An execution integration is a saved execution account/agent configuration discovered with list_execution_configs. The conversational agent you talk to uses MCP to control Factorize. The execution agent receives the job’s rendered prompt and does the work on the execution account. Giving the conversational agent MCP permission does not give the execution agent repository, provider or model access. Your saved connection, VM tags and prompt must supply those. Every job gets a manual trigger. Additional triggers have immutable server-generated slugs such as trigger-2. Each run receives only the firing trigger’s context; prompt templates use that slug.

​
Concurrency and the queue

With concurrency 1, a review already running occupies the only active slot. One more run may wait in the queue. A further manual request returns queue_full; wait for capacity instead of repeatedly changing retry keys. Automatic schedule/webhook/lifecycle signals arriving while a run is queued are skipped/coalesced, so they are not a complete event log. An accepted idempotency key still returns its original run even when the queue is full. Concurrency can be 1–50. With concurrency 2, two reviews may execute and one may wait. Queued runs keep the prompt/context they were submitted with; editing a job does not rewrite those runs. Query runs and the provider for authoritative work when automatic events coalesce. Inspect output before treating a terminal state as a useful result. Trace collection can be incomplete even when execution completed; advanced trace recovery belongs in operations.

​
Global skills

Skills are reusable, tenant-scoped instruction bodies that can be attached to jobs in an explicit order. A body is literal text: Mustache expressions, braces, Unicode, whitespace, and HTML-like text are passed through unchanged. Only the job context is rendered with trigger data. Renaming a skill changes its shared key without changing stable job references. Deletion is rejected while any enabled or disabled saved job uses it. A run resolves its selected skills when queued and stores the exact bodies, keys, revisions, and order; later edits, renames, or deletion do not change historical runs. Skill library operations require skills:read or skills:write; inspecting affected jobs also requires jobs:read.