MVP: dogfood goose autonomous tasks as actionable IDP agent work insights

[ourchitectureio]

Observation

The current autonomous-task skill already gives us a strong local operating model for AI-assisted development work:

• Plan -> review -> implement -> validate -> ship flow
• Isolated git worktrees per task
• Human or AI review gates
• Lock and heartbeat files for local session safety
• local_only=true mode for fully local runs
• OpenCode and Pi comparison hooks

This issue adds a goose dogfooding path and an IDP MVP that turns those task signals into actionable insight.

The goal is not to build another agent.

The goal is to prove the IDP can observe agent work, connect it to delivery outcomes, and answer: what should someone do differently because of this?

Why it matters

AI coding tools create local productivity signals, but those signals are usually disconnected from delivery outcomes.

A developer, architect, or leader should be able to see:

• Which agent task is active
• Who or what initiated it
• What repo, issue, service, or system it affects
• Whether it is planning, implementing, validating, blocked, or complete
• What human review is needed
• What validation failed
• What cost, model, or token signals are available
• Whether the work created value, risk, or rework

This aligns with the newer AI measurement lens: utilization, impact, and cost. It also aligns with the DORA warning that AI amplifies the surrounding engineering system. More agent activity is not the outcome. The useful signal is whether agent activity improves delivery without increasing instability or downstream chaos.

MVP scope

Dogfood goose as one supported agent runtime for the existing autonomous task workflow.

Build a small IDP surface that shows actionable agent work insight from local task execution.

This MVP should work locally first. GitHub and PR integration can be read or linked where available, but the first version should not require hosted infrastructure.

Proposed user story

As a developer using the IDP repo,
I want to run an autonomous task through goose and see the task state in an IDP view,
so I can understand what the agent is doing, where it is blocked, what needs human review, and whether the work is ready to validate or ship.

Proposed dogfood workflow

1. Install and configure goose locally.
2. Run goose against a small issue or free-form task using the existing autonomous-task skill behavior as the operating contract.
3. Keep the existing worktree, lock, heartbeat, and local-only safety model.
4. Capture a local task event stream or snapshot from the worktree.
5. Render the task as an actionable IDP insight.

Example task states:

• worktree-claimed
• planning
• needs-review
• implementing
• impl-validation-failed
• impl-validated
• ship
• complete-local
• failed
• blocked

Proposed implementation shape

1. Add a goose launcher path

Add a small local script, make target, or package command that documents and runs the goose dogfood path.

Possible shape:

make agent-goose-task ISSUE_NUMBER=123 LOCAL_ONLY=true
make agent-goose-task TASK_DESCRIPTION="small docs update" LOCAL_ONLY=true

The launcher should:

• Create or reuse the task worktree
• Set the expected worktree path
• Preserve the .agent-lock and .agent-heartbeat convention
• Start goose in a mode suitable for local dogfooding
• Prefer approval or smart approval mode for write actions during early dogfooding
• Avoid requiring remote push or PR creation for the MVP

2. Add a normalized agent task snapshot

Create a small JSON snapshot file that can be read by the IDP.

Possible path:

.agents/worktrees/<task-slug>/.agent-task.json

Possible schema:

{
  "taskId": "issue-123-example-task",
  "tool": "goose",
  "runtime": "local",
  "issueNumber": 123,
  "taskDescription": "...",
  "worktreePath": ".agents/worktrees/issue-123-example-task",
  "branchName": "task/issue-123-example-task",
  "status": "impl-validation-failed",
  "phase": "validate",
  "humanActionRequired": true,
  "recommendedAction": "Review the validation failure and decide whether to let the agent retry.",
  "lastHeartbeatAt": "2026-05-16T00:00:00Z",
  "lastErrorSummary": "make check failed in contract tests",
  "lastCommitSha": null,
  "validationCommand": "make check",
  "modelProvider": null,
  "modelName": null,
  "tokenUsage": null,
  "estimatedCostUsd": null,
  "links": {
    "issueUrl": null,
    "prUrl": null
  }
}

This file is intentionally small. It should support the IDP view before deeper telemetry exists.

3. Add a local BFF endpoint or static fixture reader

Expose active local agent tasks through the existing local dev app path.

Possible endpoint:

GET /api/agent-work/tasks
GET /api/agent-work/tasks/:taskId

The endpoint should read .agent-task.json and .agent-heartbeat files from known local worktree paths.

For the MVP, file polling is acceptable. Do not require a database.

4. Add an actionable IDP UI surface

Create a small Agent Work view.

The UI should not be a dashboard dump. It should show what needs attention.

Suggested cards:

• Needs review
• Validation failed
• Stale or possibly hung
• Ready for local review
• Completed recently

Each card should use the IDP insight shape:

Observation
The goose task for issue 123 failed validation.

Why it matters
The implementation is not ready to ship and may need test or contract updates.

What to do
Review the failure summary, then retry implementation or mark the task blocked.

5. Add minimal outcome fields

The first version should capture enough fields to support later measurement:

Utilization:

• Tool used
• Task count
• Phase reached
• Human review required
• Retry count if available

Impact:

• Validation result
• PR URL if available
• Commit SHA if available
• Files changed count if available
• Linked issue number

Cost:

• Model provider if available
• Model name if available
• Token usage if available
• Estimated cost if available

If goose OpenTelemetry or MLflow tracing is enabled locally, link to it or note its presence. Do not make it mandatory for the MVP.

Acceptance criteria

• A documented goose dogfood command or guide exists for running an autonomous task locally.
• The goose workflow preserves the existing worktree, lock, heartbeat, and local_only safety model.
• At least one local task writes or updates a normalized .agent-task.json snapshot.
• A local API or fixture reader exposes active agent task snapshots.
• A UI surface shows active and recent agent work as actionable insights, not raw telemetry.
• The UI highlights at least these states: needs review, validation failed, stale heartbeat, ready for local review, complete-local.
• The implementation includes at least one test or fixture proving that a failed validation snapshot becomes a recommended human action.
• Documentation explains how this MVP supports later utilization, impact, and cost measurement.

Out of scope for this MVP

• Full cost attribution across all model providers
• Enterprise policy engine
• Remote hosted agent execution
• Automatic PR merge
• Long-term database persistence
• Multi-user identity reconciliation
• Full OpenTelemetry ingestion pipeline

Design guardrails

• Local first.
• Human approval by default for write-sensitive actions.
• No individual productivity scoring.
• No dashboard dumping.
• Prefer actionable insight over raw events.
• Treat agents as extensions of the developer or team directing the work.
• Show uncertainty when cost, token, or model data is unavailable.

References

• Existing skill: .agents/skills/autonomous-task/SKILL.md
• goose docs: https://goose-docs.ai/docs/quickstart/
• goose permissions: https://goose-docs.ai/docs/guides/goose-permissions/
• goose observability with MLflow and OTLP: https://goose-docs.ai/docs/tutorials/mlflow/

Suggested first dogfood task

Use goose to implement the smallest slice of this issue:

1. Add a fixture .agent-task.json for a failed validation state.
2. Add a local reader that loads the fixture.
3. Add one UI card that renders Observation, Why it matters, and What to do.

That proves the IDP behavior before investing in deeper agent runtime integration.

[ourchitectureio]

Implementation clarification: goose and .agents/agent-models.yml

The MVP should not assume goose can directly consume .agents/agent-models.yml as-is.

The existing model file is currently documented around OpenCode and Pi provider IDs. The goose dogfood path should add a small compatibility layer that maps the selected IDP agent model profile into goose runtime configuration.

Recommended MVP behavior:

1. Keep .agents/agent-models.yml as the repo-level source of intent for model selection.
2. Add a small resolver script or make target that reads:
   • AGENT_MODEL_PROFILE, defaulting to default
   • role keys: plan, implement, validate, review
   • optional role overrides such as AGENT_PLAN_MODEL
3. For the first goose MVP, resolve the implement role into goose session configuration.
4. Emit the resolved provider and model into .agent-task.json so the IDP can show what was used.
5. If the selected provider/model cannot be mapped cleanly to goose, fail clearly before starting the agent.

Example desired shape:

AGENT_MODEL_PROFILE=fast make agent-goose-task ISSUE_NUMBER=370 LOCAL_ONLY=true

The launcher should resolve the fast profile, configure or invoke goose with the mapped provider/model, and write the resolved values into the task snapshot.

This keeps the IDP model configuration as the durable source of intent while allowing each runtime, including goose, OpenCode, and Pi, to have its own adapter.

[ourchitectureio]

Proposed autonomous agent assignment flow

Use this issue as a controlled dogfood run for the existing autonomous task flow.

The goal is to let agents work as autonomously as possible while preserving clear review gates, repeatable validation, and human control over scope expansion.

Recommended execution model

Use four roles. These can be separate agents, separate sessions, or one agent explicitly switching roles.

1. Planning agent
2. Plan reviewer
3. Implementation agent
4. Implementation reviewer / validator

For local dogfooding, start with local_only=true. Do not require PR creation or merge until the local flow proves useful.

Agent assignment prompt

You are working in the ourchitecture/idp repo on issue #370.

Use the existing autonomous task skill as the operating contract:
.agents/skills/autonomous-task/SKILL.md

Your job is to implement the smallest useful MVP slice for goose dogfooding and actionable IDP agent work insights.

Work in an isolated worktree.
Preserve the lock file and heartbeat model.
Use local_only=true unless explicitly instructed otherwise.
Do not merge or ship remotely without human approval.

The goal is not to build a full telemetry platform.
The goal is to prove that an agent task can produce a normalized local snapshot and that the IDP can render it as an actionable insight.

Phase 1: planning

The planning agent should produce a plan with these sections:

Summary
Files to create or modify
Approach
Patterns to follow
Risks
Verification commands
Scope exclusions
Open questions
Complexity

The plan must explicitly answer:

• Where will .agent-task.json fixtures live?
• Which BFF or local reader will expose the task snapshots?
• Which UI surface will render the insight?
• What is the smallest fixture-backed slice that proves the concept?
• How will the goose model-profile adapter be scoped without overbuilding?
• Which tests will prove failed validation becomes a recommended human action?

Stop after planning and request review.

Phase 2: plan review

The reviewer should approve only if the plan:

• Keeps the MVP small
• Preserves the existing worktree, lock, heartbeat, and local_only model
• Does not require full OpenTelemetry ingestion
• Does not require a database
• Does not turn the UI into a dashboard dump
• Produces an actionable IDP insight using Observation, Why it matters, and What to do
• Has clear verification commands
• Has at least one test or fixture proving the behavior

If the plan is too broad, reject it and ask the planning agent to reduce scope.

Phase 3: implementation

The implementation agent should implement only the approved plan.

Recommended first slice:

1. Add one fixture representing a goose task in impl-validation-failed state.
2. Add a small reader that loads local agent task snapshots.
3. Add an API route or fixture-backed service method for active agent work.
4. Add one UI card or view that renders an actionable insight.
5. Add minimal docs for running the goose dogfood path.
6. Add a small model-profile resolver only if needed for the documented goose launcher path.

Implementation rules:

• Make small commits by logical slice.
• Do not use git add ..
• Keep all generated state out of source unless it is a deliberate fixture.
• Do not introduce a database.
• Do not add remote execution.
• Do not add automatic merge behavior.

Phase 4: implementation review

The review agent should inspect the implementation against the issue and approved plan.

Review questions:

• Does the work satisfy the acceptance criteria?
• Does it keep goose support local-first?
• Does it preserve existing autonomous task conventions?
• Is .agent-task.json small, stable, and understandable?
• Does the UI tell the user what to do next?
• Are missing cost/model/token fields represented honestly as unknown or unavailable?
• Are tests and docs sufficient for a developer to try this locally?

If the review fails, return to implementation with specific change requests.

Phase 5: validation

Run the repo's normal validation command.

COMPOSE_PROJECT_NAME=issue-370-goose-agent-work make check

If narrower commands are available and documented by the implementation plan, run those first, then run make check before completion.

If validation fails:

1. Capture the failure summary.
2. Update heartbeat / task state if this is being run through the local autonomous flow.
3. Send the failure back to the implementation agent.
4. Retry until validation passes or the max implementation iteration count is reached.

Completion criteria

The work is complete only when:

• The approved plan has been implemented.
• The local fixture or snapshot can be read.
• The IDP surface renders at least one actionable agent-work insight.
• The failed validation state recommends a concrete human action.
• Missing model, token, or cost fields are shown as unavailable, not guessed.
• Docs explain how to try the goose dogfood path locally.
• Validation passes.
• A completion summary is posted with files changed, commands run, and known limitations.

Suggested local invocation

Start conservative:

AGENT_MODEL_PROFILE=fast make agent-goose-task ISSUE_NUMBER=370 LOCAL_ONLY=true REVIEW_MODE=human

Then, after the planning and implementation loop is stable, try:

AGENT_MODEL_PROFILE=fast make agent-goose-task ISSUE_NUMBER=370 LOCAL_ONLY=true REVIEW_MODE=auto MAX_PLAN_ITERATIONS=3 MAX_IMPL_ITERATIONS=3

Human review gates

Require human review before:

• Expanding the schema beyond the first MVP fields
• Adding persistent storage
• Adding OpenTelemetry ingestion
• Creating or merging a PR
• Allowing autonomous write actions outside the isolated worktree
• Changing the existing autonomous task skill behavior in a breaking way

Recommended stopping point for the first run

Stop after the IDP can show this insight from a fixture or local snapshot:

Observation
The goose task for issue 370 failed validation.

Why it matters
The implementation is not ready to ship. The failed check may indicate missing tests, contract drift, or an incomplete implementation.

What to do
Review the failure summary, then retry implementation or mark the task blocked.

That proves the product behavior before deeper runtime integration.

[ourchitectureio]

Budget constraint update: avoid API-only model usage by default

New constraint: the local dogfood flow should not assume paid API-key usage.

OpenCode with Anthropic uses API billing, not the user's Anthropic subscription. The MVP should therefore distinguish model intent from payment path.

Recommended change to the model-profile resolver:

1. Add a paymentPath or runtimeProvider concept separate from model.
2. Default local dogfood runs to subscription-backed or free paths.
3. Fail closed if a selected profile would require API-only spend and no explicit budget flag is set.
4. Capture the resolved payment path in .agent-task.json.

Suggested payment paths:

paymentPaths:
  codex-subscription:
    spendType: subscription
    allowedByDefault: true
  github-copilot-subscription:
    spendType: subscription
    allowedByDefault: true
  opencode-zen-free:
    spendType: free-limited
    allowedByDefault: true
  cursor-free:
    spendType: free-limited
    allowedByDefault: true
  local-ollama:
    spendType: local-compute
    allowedByDefault: true
  anthropic-api:
    spendType: api-metered
    allowedByDefault: false
  openai-api:
    spendType: api-metered
    allowedByDefault: false

Suggested guardrail:

ALLOW_METERED_API=true make agent-goose-task ISSUE_NUMBER=370 LOCAL_ONLY=true

Without ALLOW_METERED_API=true, the launcher should reject API-metered providers with a clear message.

Initial preferred dogfood order:

1. GitHub Copilot subscription path for Claude models where supported.
2. Codex subscription path for heavier autonomous implementation.
3. OpenCode Zen free models for low-risk planning, fixture generation, and validation experiments.
4. Local Ollama models for cheap draft planning, schema work, and docs.
5. Anthropic API only when explicitly approved.

This protects the user's budget while making cost visibility a first-class IDP signal.