Agentic Jobs

Agentic Jobs are repeatable, configurable units of AI-agent work. Each job is a definition — a prompt, a set of granted tools, a trigger, a target repository, and injected environment secrets — that runs CodeCargo's code-editor agent to perform an expected task on your behalf. Every execution is recorded as an agent run, so you can review progress and history in the same run viewer used by other agent features.

Scopes and Identity

Every Agentic Job has a scope that determines which identity it runs as and who can manage it.

Org-scoped jobs are not tied to any project. Project-scoped jobs are owned by the user who created them — commits and pull requests are attributed to that user. If the owner loses org membership, loses repo access, or their GitHub link lapses, the job fails closed rather than silently downgrading to the org identity.

Creating an Agentic Job

Org-scoped job

1. Navigate to Agentic Jobs in the organization sidebar.
2. Click New Agentic Job.
3. Fill in the job definition form (see Job Configuration below).
4. Click Create.

Project-scoped job

1. Open a project and navigate to its Agentic Jobs tab.
2. Click New Agentic Job.
3. Fill in the job definition form. The target repository must belong to the project.
4. Click Create.

Job Configuration

Prompt

The system prompt that instructs the agent what to do on each run. Write it as you would a detailed task description — the agent reads this every time the job fires.

Tools

Select which tools the agent is allowed to use. Granting write tools (for example, creating pull requests or pushing commits) to a project-scoped job requires that the job owner holds at least Write access on the target repository at the time the job runs.

When it's available to your organization, you can grant a job the Web Search tool so the agent can run live web searches for current information — for example, library versions, CVE details, or recent releases — instead of relying solely on the model's training data. The agent decides when a search is needed; you don't write search queries yourself. Each search is billed per use, in addition to your normal token costs.

MCP Server Access

In addition to built-in tools, an Agentic Job can be granted access to specific MCP servers from your organization's catalog. Only servers an Org Admin has enabled in Organization Settings → MCP Servers are available to grant.

When you add an MCP server grant to a job, you choose a subset of that server's tools — up to its configured tool cap. This subset is validated at authoring time and frozen on the job's thread, so the exact same tools are available on every turn of every run. If the server's overall tool cap is later narrowed, tools removed from the cap are automatically revoked from the job's grant the next time it runs.

At dispatch time, CodeCargo resolves each grant into a live connection: credentials are injected in transport form, and CargoWall receives a per-run allow rule for the server's host so the agent can reach it.

Trigger

Choose when the job fires:

Target Repository

The repository the agent works in. For org-scoped jobs, any repository accessible to the GitHub App is available. For project-scoped jobs, only repositories within the project are shown.

Secrets

Inject environment variables into the agent's runtime. Secret values are write-only — you can set or replace them, but you cannot read them back after saving. Use secrets to provide API keys, tokens, or other sensitive values the agent needs to complete its task.

External Event Webhooks

When you select the External Event trigger, CodeCargo mints a unique, rotatable webhook URL for the job, shown on the job's detail page. Any system that can send an HTTP POST — a Jira automation, a GitHub repository_dispatch, a tracker webhook — can use this URL to fire a run.

• Copy / Rotate — copy the webhook URL from the job's detail page, or rotate it to invalidate the old URL immediately (for example, after a suspected leak). Rotating replaces the token in the URL; any system still posting to the old URL will fail.
• Payload binding — the full JSON payload you POST is appended to the agent's prompt as an ## Incoming event block. Any top-level scalar field in the payload whose key matches one of the job's declared inputs automatically fills that input's {{placeholder}}. Binding is lenient: a missing or mismatched field resolves to empty rather than failing the run, so the agent still sees the full raw payload even if nothing binds.
• Idempotent delivery — senders that support delivery IDs can include an X-CodeCargo-Delivery header so a retried delivery doesn't trigger a duplicate run.

Generate Details Automatically

Toggle Generate details automatically when creating or editing a job to have CodeCargo generate the job's name and description for you, based on its prompt and granted tools, instead of writing them by hand.

While the toggle is on, the Name and Description fields are disabled in the form — CodeCargo keeps them current automatically, regenerating them whenever the prompt, granted tools, or MCP server access changes on a save. The icon always stays manual.

Agent Definition

Every job runs an agent definition — the prompt, engine, and requested tools. You can write the prompt inline, in which case CodeCargo keeps a private definition for that job alone, or bind an agent already published to your organization's catalog and reuse it as-is.

When you bind a published agent, the job's tool selection narrows what the agent was granted; it can never widen it. If the agent's grant is later reduced, the job's next run uses the reduced set automatically.

To turn a job's inline prompt into something other jobs can reuse, open the job and click Save as reusable agent. The definition moves into the catalog, where an Org Admin reviews and grants its tools before it becomes available org-wide.

Running a Job

To trigger a job manually:

1. Open the job's detail page.
2. Click Run Now.
3. The run appears in the Run History tab and opens in the agent run viewer.

Scheduled and trigger-based jobs fire automatically according to their configuration. All runs — manual or automatic — appear in run history.

Tool Approvals

When an agent holds a tool that was granted with approval required, the run pauses the moment the agent tries to use it and waits for a human decision. The pending request appears on the run's detail page and in the Activity pill, showing which tool the agent wants to call and with what arguments.

Only the person who started the run can approve or deny it. Approving lets that call proceed and the run continues; denying returns the refusal to the agent, which carries on without that tool. A run that is never answered stays waiting rather than completing.

Run History

Each execution of an Agentic Job creates an agent run. Open the Run History tab on a job's detail page to see the full history. Click any run to open the agent run viewer, where you can:

• Watch the activity timeline stream in real time while the run is active
• Review the completion or blocker summary once the run finishes
• Inspect child runs spawned by the lead agent (see Fan-out runs below)

Fan-out Runs

For jobs that involve multiple repositories or parallel tasks, the lead agent can spawn child runs using the SpawnChildRun tool. Each child run executes in its own workspace and appears as a linked run under the parent. This lets a single job coordinate work across many targets — for example, a release-log watcher that fans out a separate fixer task per affected repository.

Editing and Deleting a Job

From a job's detail page:

• Click Edit to update the prompt, tools, trigger, repository, or secrets.
• Click Delete (or use the Delete Job dialog) to permanently remove the job and its configuration. Run history is preserved.

Permissions Reference