Ask, Teach, Task

Every interaction with a Knowledge Pack is one of three actions. Each action is small on purpose. The actions combine with each other. One action does not take over the job of another.

Action	Intent	Pack cardinality	Durable effect	Complete when
Ask	“Give me an answer.”	Exactly one	None	A grounded answer or honest decline is returned
Teach	“Know this next time.”	Exactly one	Changes that pack’s understanding	The contribution is processed and usable by the pack
Task	“Go do this work.”	Exactly one	Creates trackable work. Pack changes must be explicit	The requested result is produced, or the blocker is reported

The cardinality is deliberate:

• Reading needs a clear scope. That is why ask targets one pack. That pack’s scope already includes any upstream packs it builds on.
• Learning needs clear ownership, a record of where each contribution came from, and conflict handling. That is why teach targets one pack.
• Work needs one owner, one activity history, and one permission context. That is why task belongs to one pack.

Ask

Ask answers a question from one pack. It uses the pack’s knowledge, connections, and data sources, plus any upstream packs it builds on. It makes no durable change to that pack. This is true however much retrieval, live reading, or multi-step computation the answer needed.

Reading an upstream pack never copies it or widens access. Each pack keeps its own identity, permissions, and sources. An answer shows which packs and sources supported it. Conflicting evidence is shown, not blended into one answer.

MCP

Say it in chat. The assistant calls ask.

“What does our company mean by activation?”

“How many active accounts did we have last quarter?”

CLI

edisyl ask <pack> "What does our company mean by activation?"
edisyl ask <pack> "How many active accounts did we have last quarter?"

When ask can’t answer, it tells you why. See Improving answers to close that gap. See Objectives to prevent gaps before anyone asks.

Known, Understood, and New questions

Every ask takes one of three routes. The route depends on how much the pack already knows about that kind of question. Known reuses a stored plan. Understood builds a plan and stores it. New explores the rest of the pack. The route changes speed and cost. It never changes whether the answer is grounded. See Known, Understood, New for how each route works and why most questions should arrive Known.

Teach

Teach makes a durable contribution or correction to exactly one pack. The target is always visible before the action is accepted. Teach is complete only when future asks and tasks can use the contribution. Accepting a file is not enough. The file must be indexed.

Teach can take a direct statement, a correction, a file, researched material, or an Ask answer worth keeping. It always targets one pack. Durable understanding needs a clear owner. Ownership sets who may change it, where its sources are recorded, and which future asks and tasks can use it.

MCP

Say it in chat. The assistant calls teach.

“Teach the pack that DLU excludes bot-authored pull requests.”

CLI

edisyl teach <pack> --text "DLU excludes bot-authored pull requests."

Note

Attaching a live connection is not teaching. A connection stays a live source of truth. Teach runs only when you explicitly ask the pack to keep a durable fact, summary, or rule.

Every teach returns a receipt: the target pack, what was learned, where it came from, whether it conflicted with existing material, and how to edit or undo it.

Task

A task asks exactly one pack to do trackable work. This includes research, curation, semantic modeling, or anything that needs more than one retrieval step. The pack provides the task’s source access, permission context, and activity history.

A task can use every source available through its pack: knowledge, connections, modeled data, and readable upstream packs. It cannot update an upstream or unrelated pack. It also does not automatically change its own pack’s understanding. These are different requests:

MCP

Say it in chat. The assistant calls task.

“Research competitor pricing and report back.”

This produces a result.

“Research competitor pricing and teach the findings.”

This produces a result and updates the pack.

CLI

edisyl task <pack> "Research competitor pricing and report back."          # produces a result
edisyl task <pack> "Research competitor pricing and teach the findings."    # produces a result AND updates the pack

How they compose

Ask   ── "teach this"          ──▶ Teach
Ask   ── "investigate further" ──▶ Task
Task  ── "retain the findings" ──▶ Teach (same pack)
Task + schedule                ──▶ Recurring task
Recurring task + teach         ──▶ Continuously maintained pack

The last line describes a self-maintaining Knowledge Pack. A recurring task reads a pack’s live sources and learned definitions and produces a result. It teaches that result back into the same pack. Future asks can then compare this week with every earlier run.

Design constraints

These rules always apply, whatever the implementation:

1. Ask is always read-only.
2. Ask, teach, and task each target exactly one pack.
3. Task changes a pack’s understanding only through an explicit teach.
4. Reading an upstream pack never merges it into the consuming pack or widens access.
5. Every answer names both the source and the pack its evidence came from.
6. Built-on (upstream) material is readable but never writable through the consuming pack.
7. How long something takes, or what kind of source it reads, never determines which action it is.

Next: Sources, for what a pack can read from and how freshness is reported.