edisyl pack objectives

An objective is a question a pack owns: declared upfront via the CLI rather than asked one at a time, then exercised in the background until the answer is cheap. Every objective command is pack-scoped except the ones that address a single objective by its own id, which derive the pack themselves.

This surface spends real money. structure, brainstorm, and examples each cost an LLM call, and a live objective drives background deep navigations at roughly a dollar apiece until it converges. Show the user what you’re about to create and wait for a yes before creating; --dry-run on structure exists for exactly that conversation.

Getting objectives in

edisyl pack objectives structure <pack> -f questions.md --dry-run   # preview, nothing written
edisyl pack objectives structure <pack> -f questions.md             # create them
pbpaste | edisyl pack objectives structure <pack>                   # or pipe a blob in
edisyl pack objectives structure <pack> --text "how many swaps last week? and by chain?"

One LLM call splits a pasted blob (a doc, a meeting note, a Claude session) into individual questions, extracts any inline hints, and topics each one.

When the user doesn’t yet know what to ask, work from the data instead. Neither of these creates anything:

edisyl pack objectives examples <pack> --limit 10        # sample questions off one source's catalog
edisyl pack objectives brainstorm <pack> --seed "revenue and churn"   # a chat session proposing candidates

Both read exactly one data source’s catalog: name the pack and they take its only source, or pass -d <data-source> to pick when it has several. Pass both and the source is checked against that pack; one belonging to a sibling pack is refused rather than quietly read. brainstorm creates nothing either — approve what survives with add.

One at a time, when you already have the wording:

edisyl pack objectives add <pack> --question "How many active wallets last week?" --topic activity \
  --hint "active = a swap in 30d; use the wallet_daily table"

A hint is human knowledge the pack can’t guess: which table to join, what a term means in your business. Same instinct as teach, aimed at one question.

Watching them converge

edisyl pack objectives list <pack>                    # every objective: status, asks, last tier
edisyl pack objectives list <pack> --status pending   # what hasn't landed yet
edisyl pack objectives asks <objective-id>            # the timeline for one

asks is the one to read: every attempt the pack made at that question, oldest first.

ASKED               STATUS     TIER      PLANE     DURATION  IN       OUT      COST
2026-08-13 21:28:50 resolved   deep      data      102.6s    647252   11039    $0.933
2026-08-13 21:43:32 resolved   rank      data      881ms     —        —        —

That’s convergence in two rows. The first attempt went to the deep tier, a full agentic navigation. Fifteen minutes later the same question came back from rank in under a second, because the pack had learned the route and cached it. That’s the whole payoff of declaring objectives: you pay for the walk once, and every later ask rides it.

A — means the ledger recorded nothing for that ask. It never means the ask was free. Every ask pays for the ask layer’s own classification, so a genuinely zero account isn’t a state this system produces. Read a dash as unknown, and never report it to the user as a free or zero-cost tier.

Status

An objective’s own status stays pending until it’s answerable, then answered. blocked means the pack gave up on it. To find out why, read asks (it prints each declined attempt’s reason beneath the table) or take the objective’s own blockedReason from get <objective-id> -j.

Editing and retiring

edisyl pack objectives get <objective-id>
edisyl pack objectives update <objective-id> --hint "<better steering>"
edisyl pack objectives archive <objective-id>    # soft delete; stops the exercise loop

Archive a bad objective rather than leaving it pending: while it’s live, it keeps buying deep navigations.

See Declaring objectives for when to reach for this instead of, or alongside, the reactive gap-routing loop.