Skip to main content
aep inspect gives you a live view of which packs are influencing agent behavior, how confident the agent is in each one, how often they have been used, and how they have evolved over time. Use it to understand what the agent is working from — and to decide what to change.

​
When to use inspect

  • Before starting a session, to verify the right packs are loaded
  • After a task, to check whether metrics updated correctly
  • When behavior feels off, to surface unexpected active constraints
  • Before promoting, to identify which packs are strong candidates

​
Example user phrases

"Which v1.0-exp AEPs are active right now, and how strong are they?"
"Show me usage metrics and recent history for the packs you're using."

​
What the inspect flow does

1

List active packs

The agent lists each currently active pack with its core identity fields:
FieldWhat it shows
idUnique pack identifier
scopetask, project, or user
version"0.1" or "1.0-exp"
titleHuman-readable pack name
applies_to summaryLanguages, frameworks, paths, and domains this pack targets
strengthPack-level confidence scalar (0–1)
2

Show metrics

For each active pack, the agent reports its usage metrics:
MetricMeaning
times_appliedHow many times this pack has been actively selected during aep apply
last_used_atTimestamp of the most recent application
avg_turns_savedRough estimate of back-and-forth messages saved per use (optional)
High times_applied combined with a recent last_used_at indicates a pack that is well-established and still relevant — a strong promotion candidate.
3

Surface active constraints, preferences, and success checks

The agent lists the specific rules currently in force, organized by type:
  • Constraints — hard rules the agent must respect
  • Preferences — softer style and approach choices
  • Success checks — verifiable conditions to confirm task completion
Rules from task packs take precedence over project packs, which take precedence over user packs.
4

Show recent history

For each active pack, the agent surfaces the most recent history entries so you can see how the pack has evolved:
[
  {
    "at": "2026-04-05T09:15:00Z",
    "event": "updated",
    "reason": "Promoted constraint to avoid redesign without explicit request"
  },
  {
    "at": "2026-03-31T10:00:00Z",
    "event": "created",
    "reason": "Initial successful HTML to Next.js migration"
  }
]
Valid event types include created, updated, promoted, and merged.
5

Highlight merge suggestions

If any active pack has merge_suggestions pointing to other packs (active or not), the agent surfaces them:
{
  "target_id": "landing-page-migration",
  "reason": "Very similar intent and constraints; consider merging packs."
}
This prompts you to decide whether to consolidate the packs.
6

Offer follow-up actions

After presenting the full picture, the agent asks whether you want to take any follow-up action:
  • Disable a pack — temporarily remove it from the active set for this session
  • Promote or demote a constraint — move a specific rule up or down in scope
  • Merge packs — act on a merge_suggestions entry
  • Archive a pack — retire a pack that is no longer useful

​
Sample inspect output

Active AEP packs (3)
────────────────────────────────────────────────────────

[1] html-to-nextjs-migration
    Scope:      task
    Version:    1.0-exp
    Title:      HTML to Next.js migration
    Applies to: typescript · nextjs · app/**, pages/**  · frontend
    Strength:   0.90
    Applied:    3 times  |  Last used: 2026-04-10T15:30:00Z

    Constraints (2):
      - Do not redesign the layout without an explicit request
      - Preserve all existing CSS class names unless the user asks to rename them

    Preferences (1):
      - Use file-based routing under pages/ rather than the app/ router

    Success checks (2):
      - All original routes render without 404s
      - Visual diff shows < 2% pixel change across key pages

    History (last 2):
      2026-04-05  updated   "Promoted constraint to avoid redesign"
      2026-03-31  created   "Initial successful HTML to Next.js migration"

    Merge suggestions:
      → landing-page-migration: "Very similar intent and constraints; consider merging."

────────────────────────────────────────────────────────

[2] project-defaults
    Scope:      project
    Version:    1.0-exp
    Title:      Frontend project defaults
    Applies to: typescript · nextjs · frontend
    Strength:   0.85
    Applied:    7 times  |  Last used: 2026-04-09T11:00:00Z

    Constraints (1):
      - All new components must have a corresponding Storybook story

    Preferences (1):
      - Prefer named exports over default exports

    History (last 1):
      2026-04-05  promoted  "Promoted from html-to-nextjs-migration"

────────────────────────────────────────────────────────

[3] user-collab-style
    Scope:      user
    Version:    1.0-exp
    Title:      Personal collaboration defaults
    Applies to: (all)
    Strength:   0.80
    Applied:    12 times  |  Last used: 2026-04-10T08:00:00Z

    Preferences (2):
      - Present options before implementing; don't act on ambiguous requests
      - Use concise summaries, not bullet walls

────────────────────────────────────────────────────────

Follow-up actions available:
  • Disable a pack for this session
  • Promote or demote a constraint
  • Merge or archive a pack

aep apply

Load and rank packs before starting a task

aep promote

Elevate proven patterns to a broader scope

Schema reference

Full field definitions including metrics and history

Prompt patterns

Example user phrases for all four commands

Build docs developers (and LLMs) love

Get started for freeTalk to us