Skip to content

Core Concepts

Agentic Unit is currently in beta. Features, supported environments, and workflows may change. Start with small, well-scoped tasks and always review the result before merging or deploying it.

Agent

An agent is an AI software engineering assistant configured with a model, instructions, and optional skills. It can inspect context, run commands, edit files, verify changes, and report its result.

Agents do not all have the same capabilities. Skills provide integrations and specialized workflows such as GitHub, Jira, Azure DevOps, pull request review, security audits, and documentation work. A task can use a capability only when the selected agent has the corresponding skill and the owning team has the required access.

Agents may be personal or team-scoped. A personal agent is visible only to its creator. A team agent is visible to members of that team.

Channels And Execution

A channel records where a job came from. Current channels include web chat, CLI, Jira, GitHub pull requests, Azure DevOps, pipelines, API callers, and schedules.

Jobs use one of two execution styles:

  • Immediate — interactive clients start an AgentCore runtime session and exchange messages with it.
  • Queued — automations and schedules place work on the job queue. The platform scheduler dispatches it when capacity is available.

The origin channel and execution style are separate. For example, web chat and CLI are interactive channels that normally start immediately, while Jira and Azure DevOps normally create queued jobs.

Team And Access Scope

The active team controls which team agents, GitHub App installation, repositories, schedules, and shared resources a user can access. Regular users see their own jobs and jobs belonging to their teams. Administrators can work across teams.

Selecting a team does not bypass the underlying integration permissions. The GitHub App, Jira technical account, Azure DevOps token, and attached skills must also authorize the requested operation.

Job Context

A job can carry several kinds of context:

  • one or more GitHub repositories;
  • one or more Jira issues;
  • persistent personal or team folders;
  • skills to make available to the agent;
  • small files attached directly to an interactive message.

The CLI can explicitly select multiple repositories. Automation payloads can also provide repository and issue arrays. Explicit context is more reliable than only mentioning a repository or issue in prose.

Runtime Workspace

Each run executes in an isolated AWS Bedrock AgentCore runtime session. Codex works under that session's workspace, where the platform materializes the selected agent configuration and skills.

Approved repositories are cloned into the workspace. Persistent folders are mounted into it, while small inline chat attachments are written to the session's uploads area. Treat the runtime as temporary: durable code output is published to a remote branch, and audit/session data is stored by platform services.

The runtime can run commands and use the network without an interactive per-command approval prompt. Access is instead constrained by the isolated runtime, its credentials, the selected team, and the enabled integrations.

Jira Work

With an appropriate Jira skill, an agent can read issue content and comments, post progress or completion comments, and—when the task explicitly requires it—change fields or apply workflow transitions. The Jira technical account's permissions are the final limit.

Production Jira automation includes the issue under context.issues and states the required outcome in prompt. Development currently uses the legacy Jira webhook, so its issue key must be included in initialPrompt. If a status, assignee, priority, label, or other field must change, say so explicitly.

GitHub Work And Results

For a normal code-change task, the standard GitHub workflow can:

  • clone an approved repository;
  • create or reuse an agent/ branch;
  • commit and push meaningful changes;
  • publish the remote branch, commit SHA, and URL as a work result.

The standard workflow does not automatically open a pull request. A developer uses the published branch to inspect the change and open or update the pull request through the team's normal process.

Agentic Unit can also review an existing pull request. This is a separate read-only workflow started by a new PR comment containing the mention configured for the current environment. See GitHub Pull Request Reviews.

Job Lifecycle

Common statuses are:

Status Meaning
QUEUED Waiting for platform capacity.
STARTING An AgentCore runtime session is being created.
RUNNING The agent is active.
COMPLETED The run finished successfully.
FAILED The run or a requested stop ended unsuccessfully.
CANCELLED A queued job was cancelled before it started.
PURGED A stale active job was force-cleaned by the platform.

Interactive clients can reconnect to active jobs and continue completed conversations by creating a continuation job. Interrupting the current turn is different from stopping the whole remote job.

Verification

Tell the agent which tests, builds, linters, type checks, or manual checks matter. The runtime can install dependencies and execute commands, but success still depends on repository configuration, available package registries, credentials, and network services.

If a check cannot run, the result should identify what was skipped and why. Run the missing checks manually before merging.

Secrets And Sensitive Data

Do not paste secrets into prompts, Jira tickets, pull request comments, or file attachments. Platform-managed integration credentials are resolved from the configured secret stores at runtime.

Trigger tokens and legacy Jira webhook keys are credentials. Store them in Jira, Azure DevOps, or CI secret storage, copy them only over approved channels, and ask an administrator to revoke and replace a credential that may have leaked.

Ownership And Review

Developers remain responsible for:

  • reviewing the published diff or review findings;
  • confirming tests and builds pass;
  • checking security, compliance, and coding standards;
  • opening and approving pull requests where required;
  • deciding whether a change should be merged or deployed.