Generate a Recurring Report — Agentic CRD Example

Why is this a Capability MLE? It has an independent purpose (a report gets produced from current data against stated parameters), a determinable outcome (a report instance, or an identifiable failure), and it stays meaningful regardless of whether an implementation already existed or had to be built first.

What does this example teach? That agent-built-software is construction provenance — how a realization came to exist — and is a separate question from execution mode — what controls it at runtime. Three realizations of the same contract show the two axes moving independently: an agent building and running an implementation; that agent-built implementation later running unattended; and that same agent-built implementation being reused under an agent's direct supervision.

Evidence status: illustrative / synthetic — written to demonstrate the model, not extracted from a real reporting system.

Identity and core meaning

NameGenerate a recurring report

DefinitionEnable a requester to receive a report, produced on a schedule or on demand, that reflects current data against stated parameters — without requiring a suitable report-generation implementation to already exist before the first request.

Capability purposeEnable a defined report to be produced repeatedly from current data, without the requester having to build or maintain the generation logic themselves.

Meaningful outcomeA report instance is produced that reflects the current data against the stated parameters, or the attempt is rejected or deferred with an identifiable reason.

IncludesSpecifying the report's parameters and cadence; producing one report instance per request or scheduled occurrence; when no suitable generation implementation yet exists, constructing and validating one as part of fulfilling that occurrence.

ExcludesAuthoring or approving the report's underlying business definition/template; distributing the produced report to its recipients; modifying the underlying source data being reported on.

Interaction Contract MLEs

Request a recurring report

Actor: Requester.
Command / intent: Define report parameters and a production cadence (on demand, or on a schedule).
Policies / invariants: Parameters must be sufficient to determine what data the report draws on and how it is scoped.
Transition: No report definition → a standing report definition.
Result: Report definition acknowledged and scheduled (or ready for on-demand production).
Events / effects: RecurringReportDefined

Produce report

Actor: An agent (while constructing and running a new implementation), or a previously agent-built implementation (running unattended, or reused under an agent's direct supervision).
Command / intent: Produce one report instance matching the current definition against current data.
Policies / invariants: A produced report instance must reflect the actual current data available at generation time — it must not silently substitute stale or cached data without disclosing that it did.
Transition: Due occurrence → produced report instance, or an identifiable failure.
Result: A report instance, or an identifiable failure reason (e.g. data unavailable, parameters no longer resolvable).
Events / effects: ReportProduced, ReportGenerationFailed

Rules and defaults

Rules / invariants

An agent-built implementation must be validated against the current report parameters before it is reused, unattended, for a subsequent occurrence. Implementation requirement.

Recommended defaults

If a previously agent-built implementation fails validation against new parameters or a changed data shape, fall back to agent-primary construction again rather than silently reusing an implementation that no longer fits. Example.

Unknown / unresolved

Exact scheduling/trigger mechanism.
Where a constructed implementation is stored, versioned, and audited.
Policy for retiring an implementation once report parameters change materially.
How a partial or degraded data source is disclosed within a produced report.

Three operational realizations — the point of this example

Realization A — agent constructs, then produces, the first occurrence

Kindagent

Execution modeagent-primary-using-software

ExposureAgent, tool

Rationale / intentThe first time this report definition is due, no suitable generation implementation exists yet. An agent interprets the parameters, determines that no reusable implementation is available, builds a function or script that produces the report from the current data, and validates it before producing this occurrence's report instance with it.

Implementation requirementThe newly built implementation MUST pass validation against the current parameters (and a known-correct sample, if one is available) before it is treated as reusable for future occurrences — not merely because it produced an output this one time.

Implementation referencesParameter-resolution tool; data-access tool; report-construction and validation tooling.

Realization B — the agent-built implementation produces subsequent occurrences

Kindagent-built-software

Execution modesoftware-primary

ExposureWorkflow, internal

Rationale / intentOnce Realization A's implementation has been validated, every subsequent due occurrence of Produce report runs that implementation directly and deterministically — the same Interaction Contract MLE and required outcome, now served by construction provenance (agent-built-software) paired with an ordinary, agent-uninvolved execution mode (software-primary). This is half of the distinction the example exists to demonstrate.

Realization C — the agent-built implementation is reused under direct agent supervision

Kindagent-built-software

Execution modeagent-primary-using-software

ExposureAgent, tool

Rationale / intentReport parameters changed since Realization A's implementation was last validated. Rather than trust it to run unattended (Realization B) or discard it and start over, an agent reuses the same agent-built implementation but directly invokes and supervises this occurrence's run, checking its output against the changed parameters before the implementation earns unattended (Realization B) status again. Construction provenance is unchanged from Realization B; only who controls this occurrence's execution differs.

Implementation requirementThe supervising agent MUST confirm the agent-built implementation's output against the current parameters before either releasing this occurrence's report or restoring the implementation to unattended (Realization B) use.

Implementation referencesThe same agent-built report-generation implementation as Realization B; parameter-resolution tool; data-access tool.

This is the other half of the distinction: agent-built-software (Realization B and C's shared provenance) pairs with both software-primary (B) and agent-primary-using-software (C) — construction provenance does not determine execution mode, and the reverse also holds, since Realization A's agent-primary-using-software pairs with kind: agent, not agent-built-software. All three realizations satisfy the same Produce report contract and the same capability; only provenance and execution mode move, and they move independently rather than together.

Optional: agentic mappings

Element	Kind	Relationship	Notes
Report-construction assistant	skill	realizes-capability	Realization A only — invoked when no valid implementation currently exists for this report definition.
parameter-resolution tool	tool	supports-contract	Supports Request a recurring report and validation in Produce report.
data-access tool	tool	supports-contract	Supports Produce report in all three realizations.
Agent-built report-generation implementation	tool	realizes-capability	Realizations B and C — the artifact Realization A constructed and validated; not a skill in either realization, since no agent reasoning occurs inside the implementation itself, only around it in Realization C.

Why this example matters

Without this example, a reader could reasonably — but wrongly — assume agent-built-software is just another name for agent-primary-using-software: that "built by an agent" and "run by an agent" are the same claim. They are not. Realization B is built by an agent and then runs as ordinary software, with no agent in the loop at execution time. Realization C uses the same agent-built implementation, but under direct agent supervision — proving that agent-built-software does not force software-primary, since B and C are both agent-built with different execution modes. Realization A shows the reverse: an agent controlling the flow without the resulting implementation itself being reused agent-built software yet — it is what B and C's implementation becomes, not what it already is while under construction. The capability, and the Produce report contract it must satisfy, do not change across any of the three — only provenance and execution mode move, and the three realizations together show that they move independently of each other, not that they merely could.