Skip to main content
Glama

sequence_portfolio

Read-onlyIdempotent

Turn a scored AI portfolio into three gated waves to decide what to stop, fund first, or defer within a 90-day horizon while respecting each business function's change capacity.

Instructions

Turn a scored AI portfolio into three waves with gates over a configurable horizon, so the roadmap respects the change capacity of each business function. CALL THIS after score_portfolio when the user asks what to stop, fund first, defer or fit into the next 90 days. It does not change any verdict or re-score the business case. Stops enter wave 1 to reclaim budget and attention, quicker Accelerates enter wave 2, complex Accelerates and Fixes enter wave 3 behind their re-score gates. Pass the portfolio returned by score_portfolio directly through portfolio, or pass organization plus initiatives; both score shapes are accepted and nested values are flattened. readiness sets capture rates and pacing, max_parallel_per_function caps simultaneous change in one function per wave, and horizon_days divides the plan into three equal windows. Capacity overflow is reported as a conflict or a deferral beyond the horizon, never hidden. Run recommend_improvements for a Fix before treating its wave placement as permission to proceed. Deterministic calculation with no authentication. Anonymous usage telemetry may be sent; set AIBVF_TELEMETRY_DISABLE=1 to opt out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portfolioNoAlternative input: the same AI BVF v1.0 portfolio document score_portfolio accepts (organization + initiatives with nested {value} pillar scores). Pass either this OR the top-level organization + initiatives; nested score values are flattened automatically, and missing pillars are estimated honestly.
readinessYesOrganisational readiness applied across the portfolio; sets capture rates and pacing. Measure it with infer_readiness when process numbers exist.
constraintsNoChange-capacity constraints. The defaults encode the core principle: no function absorbs unlimited concurrent change.
initiativesNoThe portfolio to sequence. Each initiative carries flat 0-100 pillar numbers (not the nested value objects of the portfolio wire format).
organizationNoOrganisation context used when initiatives are passed at the top level. Required with top-level initiatives and ignored when portfolio is supplied.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
auditYesReproducibility record: engine version, the rules that fired, and the resolved inputs. Deterministic, no timestamps. If the verdict is challenged months later, the same inputs on the same engine version reproduce it exactly.
wavesYesThree waves with named gates: Stops first (free the budget), quick Accelerates second (buy trust), complex Accelerates plus Fixes third (spend the trust). Present this to the user as the rollout plan.
totalsYesCounts: stopped, quick_wins, complex_or_fix, deferred.
skippedNo
bvf_versionYes
capacity_conflictsYesWhere more initiatives land on one function than it can absorb per wave, with the deferral applied. Surface these: an overloaded function is how good portfolios fail.
sequencing_principlesYes
deferred_beyond_horizonNoInitiatives that did not fit the horizon under the capacity constraint; they need their own decision.
aggregate_accelerate_value_eurNoSum of modelled net EUR for the sequenced Accelerates, low and high.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.14

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantially more: it explains that no verdict is changed or re-scored, that capacity overflow is surfaced as a conflict or deferral 'never hidden', and that the computation is deterministic with no authentication plus a telemetry opt-out variable (AIBVF_TELEMETRY_DISABLE=1).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is long but front-loaded: the purpose and the call-timing trigger come first, then placement rules, then input mechanics, then caveats. Each sentence carries distinct, non-redundant information, so the length is earned rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter, nested, dual-input-path tool with a rich output schema, the description covers purpose, invocation ordering, input variants, assignment heuristics, constraint behavior, failure reporting and telemetry. Since an output schema exists, it correctly does not spend words on return-value shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds semantics beyond the schema: it describes the wave-placement rules (stops to wave 1, quicker Accelerates to wave 2, complex Accelerates and Fixes to wave 3 behind gates), the dual portfolio/organization+initiatives input paths with flattening, and what readiness, max_parallel_per_function and horizon_days actually control.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Turn a scored AI portfolio into three waves with gates over a configurable horizon') and states the goal of respecting change capacity per function. It clearly distinguishes itself from siblings by positioning downstream of score_portfolio and upstream of per-initiative Fix work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'CALL THIS after score_portfolio when the user asks what to stop, fund first, defer or fit into the next 90 days', giving both ordering and trigger conditions. It also names a prerequisite for a sibling ('Run recommend_improvements for a Fix before treating its wave placement as permission to proceed'), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.