Home › Guides › AI sprint planning: why a probability engine

AI sprint planning: why a probability engine

AI sprint planning has two versions that look alike and are not the same: a language model that writes a plan in prose and a decision engine that returns typed answers with probabilities. This guide explains the second one from the actual code: the decide tool of the MCP server and the POST /api/decide endpoint, its three primitives, its two engines, the routing rule, the cost and how a decision gets audited. It ends with the split of work between the three hosted AI operations, the decision engine and the deterministic rules of the sprint plan.

Reviewed · Published

Two things called AI sprint planning

The first version: you ask a language model to propose a sprint plan and it returns text. The second: you give an engine a state (a ticket, a backlog, some context) and a list of typed questions, and it returns one answer per question with the chosen option, a confidence and the probability of every alternative. Both produce something that looks like a prioritisation. The difference is whether you can check afterwards what was decided and with which margin. In AI Tasker both exist and they are separated by contract: the hosted AI writes, the engine decides.

The second version is not a new idea: it is a concrete tool of the MCP server (one of the 40 it exposes) and an HTTP endpoint, POST /api/decide. Its code is in the public repository and its answers are objects with fields, not paragraphs. That changes what an agent can do with the output, and that is what this guide is about.

The three typed primitives

The decide tool accepts up to 10 questions per call. Each question declares a type, some instructions and, when needed, a criteria. The server validates the type of every question before running anything, and it accepts three primitives and no others:

Primitives accepted by the endpoint, with the answer shape each engine returns.
PrimitiveWhat you declareWhat comes back
choicecriteria as an object: 2 to 20 options, each with its descriptionthe chosen option, the confidence and the probability of every option
noulthe instructions and nothing else: it is a yes or no conditionthe probability that the condition holds
scorecriteria as an ordered array: 2 to 20 levelsthe level, the confidence, the probabilities and the scale legend
  • The context being decided on is called state and it is a non-empty string or a non-empty plain object. It carries the data the engine needs, not a briefing.
  • The choice criteria are a key and description object: the engine picks a key and the description is what gives it meaning. In score, the array of levels is ordered and that order is the scale.
  • If a question breaks the contract (for example a choice with a single option or a score with 21 levels), the server answers 400 INVALID_DECISION_REQUEST with the list of concrete errors and nothing is charged.
  • The order matters: the route validates first, charges second, and then calls the engines. A rejected request leaves no debt behind.

Why no prose changes the work of the agent

The difference with a generative model is not about style. A generative model returns text and whoever consumes it has to parse it: pull the chosen option out of a sentence, tell a list apart from a recommendation and assume the model did not invent a third option that was never on the list. With a decision engine there is nothing to parse: the answer is already split per question and its fields have names.

The product itself calls this the nexus rule: the model writes, your agent decides. The decision engine does not generate prose. If you want a paragraph explaining the decision, you write it from the probabilities; if you want the sprint goal in sentences or the breakdown of a task, that is done by the model the agent already brings.

That is why the decide tool has no generate type and why its output is not a plan. It is a decision shaped like data: it can be stored, compared and audited. The prose stays where it was, in the model that writes.

Two engines and one routing rule

There are two engines behind the same interface, and the server chooses between them according to the type of questions:

Engines behind the decision engine and their provider cost.
EngineWhat it isLatencyProvider cost
layaONNX embedded in the server process (laya-ts), with the exported weights~33 ms0
jevOpenRouter Decisions API (typesafe/jev-1.13 model)~250 ms~0.00002 $ per call, measured by the provider in usage.cost
  • With engine auto, a score scale of 5 or more levels goes to Jev and everything else goes to Laya. The reason is calibration: a wide scale needs a fine ranking, and Laya is kept for the short ones.
  • If you pass an explicit value (laya or jev), the call goes straight to that engine and automatic routing does not apply.
  • If Laya is unavailable, the call falls back to Jev and is counted as a fallback. If no engine is available at all, the answer is 503 DECISION_ENGINE_UNAVAILABLE and the 5 reserved tokens are returned.
  • GET /api/decide/stats returns average latency, errors, fallbacks and accumulated cost per engine, so you know which engine you are running on before tuning anything.

The engine is off by default

This is part of the contract and it is better said first: POST /api/decide answers 503 DECISION_ENGINE_DISABLED while DECISION_ENGINE_ENABLED is not exactly true. The gate is independent of authentication and of the rest of the product AI, so a well authenticated client runs into that 503 if nobody turned it on.

Turning it on takes two things: DECISION_ENGINE_ENABLED=true and one configured engine. Either LAYA_MODEL_DIR pointing at a folder with the exported ONNX weights (the server checks that encoder.onnx exists, so an empty folder counts as an unavailable engine), or OPENROUTER_API_KEY so Jev can reach its API. With the gate open but no engines, the answer is 503 DECISION_ENGINE_UNAVAILABLE and the charge is reverted.

Turning the decision engine on is a deployment decision, not a platform default. If your agent calls decide and gets a 503, the first job is not rewriting the prompt: it is setting the gate and configuring an engine.

A real call

The body has three fields: engine (optional, auto by default), state and questions. The example below is the one used by the token ledger regression test of the backend itself:

Request to POST /api/decide with one question of type choice.

POST /api/decide
Authorization: Bearer atkr_...

{
  "engine": "auto",
  "state": { "ticket": "me cobraron doble, quiero reembolso" },
  "questions": {
    "dept": {
      "type": "choice",
      "instructions": "¿qué equipo?",
      "criteria": { "billing": "pagos", "tech": "bugs" }
    }
  }
}

And the answer comes back in this shape:

Answer shape: engine plus an answers object with one entry per question.

{
  "engine": "jev",
  "answers": {
    "dept": { "type": "choice", "choice": "billing", "confidence": 1 }
  }
}

The server guarantees two fields: engine, with the engine that answered, and answers, with one entry per question. The fields inside each answer come from the engine, so a client must read the ones it needs per type (the option and its confidence in choice, the probability in noul, the level and its legend in score) and must not assume every question carries the same ones. When Jev answers, the payload may also carry a usage field with the cost and the input tokens reported by the provider.

Where this fits in sprint planning

The hosted AI and the decision engine are two different things, billed differently and solving different problems. The public operations catalogue publishes the three hosted AI operations, 1 unit each:

Hosted AI operations from the live catalogue (GET /api/plans).
OperationBucketUnitsWhat it does
AI_SPRINT_PLANhosted_ai1Plan a sprint with hosted AI
AI_GENERATE_TASKShosted_ai1Generate tasks from natural language
AI_BREAKDOWNhosted_ai1Break a task down into subtasks

And the decision engine is a separate tool, with its own cost of 5 tokens per call. The split is what matters when designing the agent:

  • The hosted AI writes. Planning the sprint, generating tasks and breaking a task down are writing jobs: the result is text a person will read and an agent will execute.
  • The engine decides. Picking a team, checking a condition, ordering a scale: these are closed questions, with a verifiable answer and a probability.
  • The deterministic plan of the product is a third lane. The plan produced by GET /api/sprints/:id/plan uses no LLM and no scoring: it orders by priority and date, excludes what is not eligible always with the reason visible, and leaves the commit to an explicit human click. That result is never persisted on its own.

The limits are separate from the units: the free plan includes 100 hosted AI operations and 100 agent operations per month per workspace, and the daily caps are 10 hosted AI operations and 200 authenticated requests with an API key across MCP and direct HTTP.

Why a probability can be cited

A plan in prose cannot be audited: if the model put task X ahead of task Y, nobody can reconstruct why from the same inputs. A probability can be: the answer says what was asked, which options existed, which one was chosen, with which confidence and with which probability each alternative had. That can be stored, compared across runs, contrasted with what the person decided afterwards and learned from. And it can be cited, because the answer is an object with fields and not a paragraph to interpret.

  • The decision and its reason live in the same place: the question you sent is the contract and the answer is its resolution. Nobody has to reconstruct the intent.
  • It is reproducible in the same sense as the rules of the sprint plan: same inputs, same order, same exclusions with the reason on display.
  • The confidence lets the client set a threshold: if it drops below what your flow accepts, that question escalates to a person instead of running blind.
  • The trail can be compared with what happens on the board: the same agent operation that creates or moves the task leaves its actor and its date in the history, and the decision sits next to it.

When a generative model is the right tool

Neither piece replaces the other. The decision engine does not write, does not qualify and does not know the context of your team: ask it for the release notes and it cannot. And a generative LLM gives you no probability to compare against. There are cases where the generative model is the right tool:

  • Release notes and the summary for a person: the value there is in the writing and the reader is human, not a program that will parse the answer.
  • The sprint goal in sentences, the rejection message of a task or the text of a webhook for a customer: prose addressed to people.
  • Open exploration, when you still do not know what to ask. An engine answers the questions you posed: if the problem is not formulated yet, there is no scale to order.

The practical rule is the nexus one: if a person is going to read the result, a model writes it; if a program is going to execute it and somebody is going to review it later, it should be a typed decision with its probability.

Checklist for deciding where each thing goes

  • Is the result read by a person or consumed by a program? (text or typed decision)
  • Can the question be written as choice, noul or score with its criteria? (if not, it is a prose case)
  • Will you be able to repeat the call with the same state and compare the answers? (auditability)
  • Is the gate on in your deployment and is an engine configured? (if not, 503)
  • Does the cost per call fit the agent budget? (5 tokens per call)
  • Does the decision reach the board, or does it stay a paragraph? (real integration)

What is left to decide

The gap in this niche is not AI that plans sprints: several tools do it and they charge per user per month. The comparison in this series reviews them against their official pages. The gap is narrower and more concrete: a plan whose justification can be checked again. The AI Tasker decision engine costs 5 tokens per call, returns typed answers and does not write; the sprint plan that goes with it is deterministic and shows the reason for every exclusion. If the question you are asking is what this agent should do first, an LLM answers you fast. If the question is why it did that and can I audit it, you need the answer with fields.

How to decide with the typed engine inside your sprint flow

Four steps to go from a question in prose to a typed answer with a probability: define the state, write the questions, call decide and check the answer contract.

  1. Define the state being decided

    Pick the state field: a string with the minimum context or a plain object. In the backend regression example it is the ticket that has to be classified. The server requires it to be non-empty, and that field carries the data, not the instruction.

  2. Write the questions with the three primitives

    choice to pick between 2 and 20 described options, noul for a yes or no condition and score for an ordered scale of 2 to 20 levels. Maximum 10 questions per call, each one with its instructions.

  3. Call decide and check the contract

    POST /api/decide or the decide tool of the MCP server. The answer carries engine and answers. Read the fields that belong to each question type and do not assume the ones that do not come; with the jev engine a usage field with the call cost may arrive as well.

  4. Store the decision and turn it into action

    Write the question and the answer in your own record and carry the decision to the board with the agent tools. If the answer is a 400, nothing was charged: fix the body and try again with the same state.

Frequently asked questions

What is the difference between the decision engine and an LLM that writes a plan?

The engine returns typed answers per question (the chosen option, the confidence and the probabilities) and generates no text; an LLM returns prose you have to parse to find out what it decided. In AI Tasker the split is explicit: the model writes and the agent decides. The decide tool exposes the choice, noul and score primitives, and its output is not a plan.

How much does a decision cost?

5 tokens per call, charged in two phases: they are reserved when the request validates and confirmed when the answer arrives. A 400 INVALID_DECISION_REQUEST is not charged and a 503 with no engines available returns the reserved tokens. The 500 credit pack for 5 € buys 100 decisions, and the laya engine adds no provider cost.

Why does the /api/decide endpoint answer 503?

Because the decision engine is off by default. DECISION_ENGINE_ENABLED has to be exactly true and one engine has to be configured: LAYA_MODEL_DIR with the exported ONNX weights or OPENROUTER_API_KEY for Jev. With the gate closed the answer is 503 DECISION_ENGINE_DISABLED; with the gate open but no engines, 503 DECISION_ENGINE_UNAVAILABLE and the charge is reverted.

Sources

Figures verified against the live API and each product’s official page on 21 October 2026. Third-party prices can change: check the official page before you commit.

Related guides

This guide exists to be indexed and cited. It is deliberately not in the menu.