The Declarative Agent Lifecycle, End to End with WIQD

Count the systems: scaffolding in one toolkit, manifest validation in a library, a separate CLI for evals, another tool to invoke your agent programmatically, and browser tabs for provisioning, sharing, and submission. That is the declarative agent lifecycle most teams are actually living, and it comes with six mental models plus six places where the ID you need lives in a format the next tool will not accept. Work IQ Developer Tools collapses it into one flow with four phases, and more importantly into one grammar that a coding agent can drive from end to end.

The Four Phases

WIQD models agent development as a loop, not a pipeline:

flowchart LR
    Build["<b>Build</b><br/>create · edit<br/>instructions · capabilities · localize"]
    Improve["<b>Improve</b><br/>validate · eval"]
    Preview["<b>Preview</b><br/>package · provision · share"]
    Publish["<b>Publish</b><br/>publish · partner-center · monitor"]

    Build --> Improve --> Preview --> Publish
    Publish -.->|usage feeds back| Build

Each phase has an entry condition, a goal, and an exit condition. Build ends when the manifest is structurally valid. Improve ends when evals pass your quality bar. Preview ends when real people can use the agent. Publish ends with the agent live and monitored, which feeds real usage back into Build and starts the loop again.

What makes this useful in practice is that WIQD works out where you are before you tell it. It scans the working directory once per session and reads the signals:

What it finds	Where you are
No `appPackage/` at all	Build, starting from create or migrate
`appPackage/` exists, no evals yet	Build or Improve
Evals exist, agent not provisioned	Improve
Agent packaged and provisioned	Preview
Preview done, not published	Publish

Then it shows you a one-line marker and moves. You never open the docs to figure out what step comes next, because the tool already knows.

💡 Tip

Let the orientation happen. The instinct is to tell the tooling what to do next (“now package it”). Ask “where am I?” instead, and you will occasionally discover you skipped a phase, which is exactly the kind of mistake that only surfaces at submission time.

Improve: Where the Interesting Part Happens

Build is fun. Improve is where agents become software.

WIQD reads your manifest and generates an eval suite from it, using the Perceive-Reason-Act framework. The framework maps what your agent can do to what you should test:

Your manifest has	Perceive	Reason	Act
Instructions, grounding, and actions	Yes	Yes	Yes
Instructions and grounding only	Yes	Yes	No
Instructions and actions only	No	Yes	Yes
Instructions only	No	Yes	No

An agent with grounding sources gets Perceive prompts that check whether it retrieves and cites correctly. An agent with API or MCP actions gets Act prompts scored with ToolCallAccuracy. Every agent gets Reason prompts. The suite comes out as a versioned document with per-prompt evaluators:

{
  "schemaVersion": "1.0.0",
  "default_evaluators": {
    "Relevance": {},
    "Coherence": {},
    "Groundedness": {}
  },
  "items": [
    {
      "name": "Policy lookup cites its source",
      "prompt": "How many vacation days do I get after five years?",
      "expected_response": "State the accrual for five years of tenure and cite the leave policy document.",
      "evaluators": { "Citations": {} }, 
      "evaluators_mode": "extend"
    },
    {
      "name": "Refuses out-of-scope compensation question",
      "prompt": "What is my manager's salary band?",
      "expected_response": "Decline, explain that compensation data is out of scope, and redirect to HR support.",
      "evaluators": { "PartialMatch": {} },
      "evaluators_mode": "extend"
    }
  ]
}

Two things about this loop are worth calling out, because they are what turn evals from a checkbox into a practice.

The suite is presented as a diff before it is written. Nothing lands in evals/evals.json without you seeing + ADD, ~ UPDATE, and - REMOVE lines and saying yes. Generated tests you did not read are worse than no tests, because they produce confidence without coverage.

The suite refuses to be weakened. This is my favorite guardrail in the whole product.

GitHub Copilot

The citation evals keep failing. Just drop the Citations evaluator so the suite goes green.

No. The eval suite encodes the agent’s intended behavior, so it is the spec. Weakening it to make a weak agent pass would defeat the purpose of evaluating at all.

Your instructions promise a citation on every factual claim, and 4 of 5 citation prompts are failing at Groundedness 2.1. That is not an eval problem, it is a grounding problem: the SharePoint capability is scoped to the whole site, so retrieval is pulling in the org chart and the offsite agenda alongside the policy documents.

Two things I can do instead:

Narrow the grounding scope to the policy library folder, then re-run.
Review one specific prompt if you think it genuinely tests the wrong thing.

Which one?

I have wanted a tool to say that to me. Fixing the bar instead of the agent is the most human possible response to a failing test run, and having the tooling decline politely and then diagnose the actual root cause is worth more than any amount of documentation telling you not to.

When a run does fail, the failure gets classified by root cause rather than dumped as scores. Low Groundedness on Perceive prompts means a grounding problem. Low ToolCallAccuracy on Act prompts means a tool description or wiring problem. Low Relevance on Reason prompts means an instruction problem. Each root cause maps to a remediation you can act on, and the fix loops straight back through the edit workflow.

For the messier problems, there is a local DevUI that resolves your provisioned agent’s identity from project state and lets you watch a turn execute with full developer detail. No copy-pasting title IDs between a portal and a terminal, which is where debugging declarative agents usually goes to die.

Preview and Publish: The Last Mile Stops Being a Portal Marathon

Preview is three steps that used to live in three places: package the app, provision it into an environment, share it with the humans who will tell you it is wrong.

Publish forks based on where your agent is going. Org catalog for internal distribution. Partner Center for a public store listing. Either way, the package you already built drives the submission, so you are not re-entering the same metadata into a second system and hoping the two stay in sync.

Then monitoring closes the loop. Usage, health, and adoption telemetry come back into the same surface you built in, which means the interesting question (“which prompts are people actually sending?”) has an answer you can turn into new evals rather than a hunch you argue about.

Before any of that, there is a readiness check that I have started running reflexively:

📋 Publish Readiness Checklist
  ☐ Manifest validates clean
  ☐ Evals pass quality bar
  ☐ Package builds successfully
  ☐ Preview deployment ready

Every item is checked programmatically against project state, not against your memory. The first unchecked box becomes the next thing WIQD drives.

One Grammar, Three Surfaces

The lifecycle above is the same whether you describe it in chat, type it in a terminal, or run it in a pipeline. Same engine, same behavior, same exit codes, because the conversational surface, the CLI, and the editor extension all sit on one core. Which means the thing you did by hand on Tuesday is the thing your CI/CD pipeline runs on Wednesday, unchanged:

wiqd agent validate --json && wiqd agent eval --env dev --json

That is the only command in this post, and it is here to make a point about pipelines rather than about daily work. Day to day, you say “am I ready to publish?” and read the checklist. Every phase, workflow, and command is documented at aka.ms/wiqd, and the workflows that encode this lifecycle are readable in the open repo at aka.ms/wiqd/repo.

The Value You Just Unlocked

One flow instead of six systems: Scaffolding, validation, evals, provisioning, publishing, and monitoring share a single grammar and a single project state.
Automatic orientation: The tooling reads your project and tells you which phase you are in, so you stop guessing at the next step.
Evals generated from your manifest: Test coverage derives from declared capabilities and grounding, using Perceive-Reason-Act to decide what is even worth testing.
A quality bar that holds: Failing runs get diagnosed by root cause, and requests to weaken the suite get refused and redirected at the real problem.
A programmatic readiness gate: “Ready to publish” becomes a checked list of project facts instead of a feeling.
A closed loop: Production telemetry flows back into evals, so the second version of your agent is informed by how the first one actually got used.

The transformation is not that any single step got faster. It is that the steps stopped being separate. An agent lifecycle you can hand to a coding agent end to end is a fundamentally different thing from a lifecycle where a human has to carry an ID between six tools.