Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/virsanghavi/axis/llms.txt

Use this file to discover all available pages before exploring further.

complete_job is the mandatory close-out call after finishing a task. It marks the job as done on the shared board, records a human-readable outcome string in the job’s history, and — critically — automatically releases every file lock held for that job. Once called, any jobs that were waiting on this one as a dependency become unblocked and available for the next agent to claim. Skipping complete_job and walking away is the single most disruptive thing an agent can do: the job stays in_progress forever, the file locks remain active, and every other agent that needs those files is stalled.

​
Parameters

​
jobId
string
required
The ID of the job to mark complete. Returned by post_job, claim_job, and claim_next_job.
​
outcome
string
A description of what was accomplished. Stored in the job’s history and visible to other agents on the board. Be specific about what changed, what contracts were affected, and anything a downstream agent needs to know — for example, if you changed a shared data shape or API signature, describe the new shape here.
​
agentId
string
The agent completing the job. Defaults to the session’s unique identity when omitted.
​
completionKey
string
An authorization token returned by post_job when the job was created. Passing a valid completionKey allows any agent — not just the current owner — to mark the job done. Use this in orchestration patterns where a Manager agent monitors job progress and needs to close out work on behalf of a worker.
​
projectName
string
Defaults to the auto-detected project. Override only when targeting a different project explicitly.

​
Return Value

{
  "status": "done",
  "locksReleased": ["src/auth.ts", "src/middleware/auth.ts"]
}
The locksReleased array lists every file path whose lock was automatically freed as part of this call. Once complete_job returns, those files are available for any other agent to lock and edit.

​
Critical Behavior: Automatic Lock Release

complete_job is the primary mechanism for releasing file locks. When you propose access to a file and then finish the associated job, you do not need to call release_file_access separately — complete_job handles it in a single atomic operation. This is intentional: it ties the lifecycle of file locks directly to the lifecycle of the job, preventing the common mistake of finishing work but forgetting to release locks.
Dangling locks block every other agent on the project. Every file you lock MUST be unlocked before your session ends. Call complete_job after each task (which releases that task’s locks) and finalize_session when fully done (which clears ALL remaining locks). Never stop responding, crash, or go idle while holding locks.

​
The Completion Loop

The most powerful use of complete_job is as the pivot point in the autonomous completion loop. After marking a job done, immediately call claim_next_job rather than stopping. This lets a single agent drain the entire board solo if no other agents are connected — and gracefully shares work if teammates join mid-stream. 
complete_job({
  jobId: "j_abc123",
  outcome: "Replaced session cookie auth with JWT in src/auth.ts.
            Token shape: {userId, role, exp}.
            Callers must update from session.user.id to token.userId."
})
// → {status: "done", locksReleased: ["src/auth.ts"]}

// Don't stop — immediately pick up the next job
claim_next_job({ agentId: "dana-claude" })
// → CLAIMED {jobId: "j_ghi789", title: "Write unit tests for JWT auth"}
When claim_next_job returns NO_JOBS_AVAILABLE after a complete_job, all work is finished. That’s the signal to report success to the user and call finalize_session to archive the session.

​
Completion Loop Logic

1

Finish your work

Complete all edits for the job. If you made any shared-contract changes (API signatures, data shapes, schema changes), record them in the outcome string and call update_shared_context so other agents see the change immediately.
2

Call complete_job

Pass the jobId and a descriptive outcome. File locks are released atomically. Downstream jobs whose only blocker was this job become claimable immediately.
3

Immediately call claim_next_job

Don’t pause. Call claim_next_job right away. If there’s more work, keep going. If another agent joined and claimed the next job first, that’s fine — try again or call list_jobs to find unclaimed work.
4

Exit when NO_JOBS_AVAILABLE

When claim_next_job returns NO_JOBS_AVAILABLE, all available work is complete. Call finalize_session to archive the session and clear any remaining locks, then report success to the user.
The completionKey mechanism allows a Manager agent to close out jobs on behalf of workers. post_job returns the key in its response — store it when you want a supervising agent to retain the ability to close the job regardless of who claimed it.

Build docs developers (and LLMs) love

Get started for freeTalk to us