Create Goals

A goal is a scoped unit of work with a clear outcome. When you tell IAS "Add a user settings page with theme preference," that becomes a goal. Goals are the primary way work flows through IAS -- from your initial description, through AI-powered refinement, to agent execution and a pull request.

How Work Enters the System

Work follows a four-step path from idea to execution:

1. Create an intake -- describe what you want done.
2. Review the goal proposal -- IAS refines your intake into a structured plan.
3. Approve the proposal -- this starts a run.
4. Monitor the run -- agents execute, and you answer decision requests along the way.

Step 1: Create an intake

An intake is the front door for getting work into IAS. It captures your raw intent -- a description of what you want to accomplish, in plain language.

To create an intake in the Command Center:

1. Navigate to Intakes in the sidebar (or from the repository detail page).
2. Click New Intake.
3. Describe the work you want done. This can be as brief as a single sentence or as detailed as a full specification.
4. Optionally attach context: links to tickets, design docs, screenshots, or reference files.
5. Select a target repository (or leave it unset to decide later).
6. Submit the intake.

You do not need to be precise about scope, architecture, or implementation details at this stage. The intent review process handles that refinement.

Step 2: Intent review and goal proposal

After you submit an intake, IAS processes it through an AI-powered intent review. This review analyzes your description and produces a structured goal proposal that includes:

• Scope definition -- what the goal covers and what it does not.
• Implementation plan -- the proposed approach, broken into logical steps.
• Readiness scorecard -- a set of gates that indicate whether the goal is well-defined enough to execute. The scorecard highlights missing information, ambiguous requirements, and potential risks.
• Blocking questions -- decision requests for critical gaps that must be resolved before work can start.
• Uncertainties -- non-blocking assumptions and risks that the agent has identified. These may be resolved during execution or escalated later.
• Autonomy level -- a recommendation for how much independence the agent should have during execution (higher autonomy for well-defined goals, lower for ambiguous ones).

The goal proposal is your checkpoint. Review it carefully before approving.

Step 3: Approve the proposal

Once you are satisfied with the proposal:

1. Resolve any blocking questions (these appear as decision requests in the proposal view).
2. Adjust the autonomy level if the default does not match your preference.
3. Click Approve (or Convert to Run in the proposal detail view).

Approval triggers two things:

• A create_run job is enqueued, which creates the run artifact bundle in your repository.
• Optionally, a kickoff work job is enqueued to begin implementation immediately.

If the proposal has unresolved blockers or fails readiness gates, the system will prevent conversion. This is enforced server-side -- the UI is not the only guardrail.

Step 4: Monitor the run

After approval, the goal becomes a run and enters the execution phase. See "The Run Lifecycle" below for what happens next.

The Run Lifecycle

Once a goal is approved and the run is created, agents take over. Here is what happens:

Agent claims the work

A connected agent (see Execution Modes) claims the first job from the queue. If you are using Console-managed mode, the Command Center routes the job to an available agent. If you are using the automated runner, the local runner daemon picks it up.

Work happens in a branch

The agent creates a working branch (or uses the branch specified in the run configuration) and begins making changes. All code modifications, documentation updates, and context adjustments are committed to this branch.

Decision requests if blocked

When the agent encounters ambiguity or needs a judgment call, it creates a decision request rather than guessing. Decision requests appear in your Inbox. You can answer them from the Command Center, and the agent continues once it has your response.

Not all questions are blocking. Agents will make reasonable assumptions for low-risk decisions and record those assumptions in the run artifacts. Only genuine uncertainties that could lead to wasted work or incorrect outcomes get escalated to you.

PR opened when complete

When the agent finishes the work, it opens a pull request against the target branch. The PR includes:

• The code changes themselves.
• A summary of what was done and why.
• Links back to the goal and run artifacts for traceability.

You review the PR through your normal code review process. If changes are needed, you can request revisions (which may trigger additional agent work) or make edits yourself.

Goal Artifacts

Every goal produces a set of artifacts stored in your repository at:

docs/ias/runs/YYYYMMDD-<slug>/

For example, a goal created on February 14, 2026 with the slug user-settings would live at docs/ias/runs/20260214-user-settings/.

This directory contains:

Because these artifacts are committed to Git, they are versioned, searchable, and portable. You can always trace back from a code change to the goal that produced it.

The Command Center also maintains a pointer to each goal for dashboard visibility. But the repository is always the authoritative record.

Tips for Writing Good Intakes

The quality of your intake directly affects the quality of the goal proposal and ultimately the agent's output. A few guidelines:

Be clear about the outcome. Describe what you want to exist when the work is done, not the steps to get there. "Add a /settings page where users can change their display name and select a dark/light theme" is better than "modify the user module."

Include constraints. If there are things the agent must not do, say so up front. "Do not modify the public API" or "Must work with the existing PostgreSQL schema" saves a round-trip of decision requests.

Attach reference material. Links to design documents, existing tickets, screenshots, or example implementations give the agent richer context to work with. The intent review will incorporate this material into the proposal.

Scope to a single deliverable. Goals that map to one pull request tend to produce the best results. If your idea spans multiple features or repositories, consider splitting it into separate intakes.

Do not over-specify implementation. You can describe the desired behavior without dictating the exact code structure. The agent (and the intent review) will work out the implementation approach. If you have strong preferences about architecture, state them as constraints rather than step-by-step instructions.

Provide context about why. A sentence about why this work matters helps the agent make better trade-off decisions during execution. "Users have been requesting dark mode for months and it is blocking our enterprise deal" gives the agent a very different priority signal than just "add dark mode."

Creating Goals Without the Console

If you are using interactive or automated mode without the Command Center, you can create goals directly from the CLI:

ias new-run user-settings

This creates the run artifact directory (docs/ias/runs/YYYYMMDD-user-settings/) with template files for you to fill in. You then populate the goal description, constraints, and plan manually (or let an interactive agent help you).

The CLI path skips the intent review and proposal workflow -- it gives you the raw scaffold. This is useful for developers who prefer to define goals themselves and want the lightest possible process.