Goal of this module
Add intelligence to TaskFlow: a task-triage crew that reads a new task's description and decides its priority. You'll build the crew, wire it into a logic block with run_crew, and invoke it.
Two shapes of AI
AI on nostackai comes as a single step inside a logic block (ai_call) and as a deployable crew you invoke as a unit. For a one-shot classification, ai_call is enough; we'll use a crew here so you see the full agentic path.
Providers are configured for you
AI steps and crews call a configured AI provider (Anthropic, OpenAI). On a managed org these are set at the platform level — you select a model, you don't manage API keys. Confirm a provider is available before building.
Option A · The simple path — ai_call
If all you need is a priority label, a single ai_call step inside a logic block does it. It's the right tool when there's no multi-step reasoning or tool use.
{
"type": "ai_call",
"outputAs": "priority",
"config": {
"intent": "classify",
"outputFormat": "category",
"categories": ["low", "medium", "high"],
"contextFields": [
{ "label": "title", "value": "{{input.title}}" },
{ "label": "description", "value": "{{input.description}}" }
],
"instructions": "Set priority high if the task is time-sensitive, customer-facing, or blocking. Otherwise medium or low."
}
}Option B · The crew path
A crew is a multi-agent workflow you build on a canvas — agents (each with a prompt and a model), wired with logic nodes, plus guardrails and memory. You deploy it, give it a status, and invoke it as one unit. For triage, a single agent with a tight prompt and a guardrail is plenty — but the same shape scales to many agents.
- Agent — a system prompt + model. Ours: a triage agent that returns
low | medium | high. - Guardrails — constrain behaviour (allowed/blocked topics, write-tool approval).
- Memory — how prior turns are retained; not needed for stateless triage.
Deploy nudges you for guardrails
Deploying a crew with no guardrails prompts you to add them first — a deliberate nudge to make agent behaviour intentional before it goes live. Add a guardrail that constrains output to the three priority values.
1 · Build & deploy the crew
task-triage.task-triage).2 · Invoke it from a logic block
Crews compose with the rest of the platform through the run_crew step. Build a triage-task logic block: read the task, run the crew on its text, write the result back to priority.
Logic block: triage-task (pathid = taskId)
s1: get_entity(task, id: {{input.pathid}}) -> task
s2: run_crew(crewSlug: "task-triage",
input: {{task.title}} + {{task.description}}) -> s2
s3: update_entity(task, id: {{input.pathid}},
set: { priority: {{s2.outputSnapshot}} })You can also invoke a deployed crew directly on the app gateway, outside a logic block:
POST /app/{orgCode}/agents/task-triage/invokeStreaming for long runs
For token-streaming or long agentic runs, invoke over the WebSocket customapi_run action instead — ai_call steps stream tokens live so a client can render output as it's produced rather than waiting for the whole response.
3 · Evaluate it
Before trusting a crew in production, run an eval: a set of inputs with expected outputs, scored in a batch. Add a few sample tasks with known priorities and run an eval to see how the crew scores.
POST /api/agents/{crewId}/eval-runsTry it
Build and deploy the task-triage crew, then call triage-task on the task whose description mentions the broken checkout link. Confirm priority comes back high. Try a mundane task and confirm it lands lower.