{"slug": "from-transcript-to-typed-action-items-three-parallel-agents-in-typescript", "title": "From Transcript to Typed Action Items: Three Parallel Agents in TypeScript", "summary": "A developer built a meeting summarizer in TypeScript using three parallel agents, each specialized for a single task: prose summary, typed action items, and per-speaker sentiment. The agents run concurrently because none depends on another's output, and a fourth agent merges the results into a structured Markdown report. The approach avoids the common pitfalls of a single LLM prompt, such as mixed output formats and missing structured data.", "body_md": "The usual way to summarize a meeting with an LLM is one prompt: \"Here's the transcript — give me a summary, pull out the action items, and tell me how everyone felt.\" One call, one model, one blob of text back.\n\nIt works on a demo and frays on a real transcript. Those are three different jobs with three different shapes. A summary wants to flow as prose. Action items want to be a strict list with an owner on every row. Sentiment wants one verdict per speaker. Cram them into a single prompt and they fight: the model pads the summary into the action items, or it forgets to tag a speaker, or the \"action items\" come back as a paragraph you now have to parse by hand. You also pay for all of it serially, and you get back unstructured text when half of what you wanted was structured data.\n\nThere's a cleaner shape. Run three specialists, each doing exactly one job, each at its own temperature, two of them returning typed objects instead of prose — and run them at the same time, because none of them needs another's output. Then a fourth agent merges the three results into one report.\n\nThis post builds exactly that, from the [ meeting-summarizer cookbook example](https://github.com/open-multi-agent/open-multi-agent/blob/main/packages/core/examples/cookbook/meeting-summarizer.ts) in open-multi-agent. The whole thing is ~280 lines of TypeScript and the parallelism is the point.\n\nThe end product is a single Markdown report with a fixed shape — a prose summary, an action-item table, per-person sentiment, and synthesized next steps. Here's the action-item section from a real run against a 21-line engineering standup — every row came back as typed data, not prose the script had to parse:\n\n| Task | Owner | Due |\n|---|---|---|\n| Deploy shadow-write harness for billing-v2 migration | Raj | 2026-04-24 |\n| Add covering index to reconciliation query before cutover | Raj | 2026-04-28 |\n| Flip feature flag for checkout redesign to 5% traffic | Priya | 2026-04-23 |\n| Draft proposal for mandatory second reviewer on multi-region changes | Dan | 2026-04-27 |\n| Create handoff doc for primary on-call rotation | Dan | — |\n| Follow up with Len about authz refactor timeline | Maya | — |\n\nThe full report also carries the three-paragraph summary, a per-speaker sentiment read, and a synthesized Next Steps list. All of it is produced by four agents — three of which ran concurrently. Here's how it's wired.\n\nEach specialist is a plain `Agent`\n\nwith its own system prompt and temperature. Start with the summarizer — prose out, no schema, a slightly higher temperature so it reads naturally:\n\n``` js\nconst summaryConfig: AgentConfig = {\n  name: 'summary',\n  model: 'claude-sonnet-4-6',\n  systemPrompt: `You are a meeting note-taker. Given a transcript, produce a\nthree-paragraph summary:\n\n1. What was discussed (the agenda).\n2. Decisions made.\n3. Notable context or risk the team should remember.\n\nPlain prose. No bullet points. 200-300 words total.`,\n  maxTurns: 1,\n  temperature: 0.3,\n}\n```\n\nThe other two specialists are where this stops being \"call an LLM three times\" and starts being reliable: **they return typed objects, not text.** You declare a Zod schema, hand it to the agent as `outputSchema`\n\n, and read the parsed result off `result.structured`\n\n.\n\nAction items are a list, and every item must carry an owner. The due date is optional, because real meetings only sometimes name one:\n\n``` js\nconst ActionItemList = z.object({\n  items: z.array(\n    z.object({\n      task: z.string().describe('The action to be taken'),\n      owner: z.string().describe('Name of the person responsible'),\n      due_date: z.string().optional().describe('ISO date or human-readable due date if mentioned'),\n    }),\n  ),\n})\n\nconst actionItemsConfig: AgentConfig = {\n  name: 'action-items',\n  model: 'claude-sonnet-4-6',\n  systemPrompt: `You extract action items from meeting transcripts. An action\nitem is a concrete task with a clear owner. Skip vague intentions (\"we should\nthink about X\"). Include due dates only when the speaker named one explicitly.\n\nReturn JSON matching the schema.`,\n  maxTurns: 1,\n  temperature: 0.1,\n  outputSchema: ActionItemList,\n}\n```\n\nNote the temperature: `0.1`\n\n. Extraction is not a place for creativity — you want the same transcript to yield the same action items. And because `outputSchema`\n\nis set, `result.structured`\n\ncomes back as a typed `{ items: [...] }`\n\nyou can push straight into Jira or Linear. No regex, no \"parse the markdown table the model hopefully produced.\"\n\nSentiment is the same idea with a tighter constraint — `tone`\n\nis an enum, so the model can only return one of four values, and every verdict has to cite evidence:\n\n``` js\nconst SentimentReport = z.object({\n  participants: z.array(\n    z.object({\n      participant: z.string().describe('Name as it appears in the transcript'),\n      tone: z.enum(['positive', 'neutral', 'negative', 'mixed']),\n      evidence: z.string().describe('Direct quote or brief paraphrase supporting the tone'),\n    }),\n  ),\n})\n```\n\nThe `evidence`\n\nfield is a cheap hallucination guard: forcing the model to attach a quote to each tone keeps it from inventing a mood nobody expressed. (One naming gotcha if you adapt this: the outer keys are plural — `items`\n\nand `participants`\n\n— and the arrays live under them.)\n\nNone of the three specialists depends on another — they all read the same transcript and write independent outputs. That's the textbook condition for fan-out. open-multi-agent's `AgentPool`\n\nruns agents concurrently up to a limit; give it three slots, add the agents, and kick them all off with `Promise.all`\n\n:\n\n``` js\nfunction buildAgent(config: AgentConfig): Agent {\n  const registry = new ToolRegistry()\n  registerBuiltInTools(registry)\n  const executor = new ToolExecutor(registry)\n  return new Agent(config, registry, executor)\n}\n\nconst pool = new AgentPool(3) // three specialists can run concurrently\npool.add(buildAgent(summaryConfig))\npool.add(buildAgent(actionItemsConfig))\npool.add(buildAgent(sentimentConfig))\n\nconst specialists = ['summary', 'action-items', 'sentiment'] as const\n\nconst parallelStart = performance.now()\nconst timed = await Promise.all(\n  specialists.map(async (name) => {\n    const t = performance.now()\n    const result = await pool.run(name, TRANSCRIPT)\n    return { name, result, durationMs: performance.now() - t }\n  }),\n)\nconst parallelElapsed = performance.now() - parallelStart\n```\n\nOne subtlety worth knowing: `AgentPool`\n\nholds a per-agent lock, so the *same* agent can't run twice at once — but three differently-named agents run truly in parallel. A pool size of 3 is exactly enough to fit them.\n\nNow the part most fan-out tutorials skip: **proving it actually ran in parallel.** Measure two things — the wall-clock time around the whole `Promise.all`\n\n, and the sum of each agent's own duration. If the work really overlapped, the wall time is much smaller than the sum:\n\n``` js\nconst serialSum = timed.reduce((acc, r) => acc + r.durationMs, 0)\nconsole.log(`Parallel wall time: ${Math.round(parallelElapsed)}ms`)\nconsole.log(`Serial sum (per-agent): ${Math.round(serialSum)}ms`)\nconsole.log(`Speedup: ${(serialSum / parallelElapsed).toFixed(2)}x`)\n\nif (parallelElapsed >= serialSum * 0.7) {\n  console.error('ASSERTION FAILED: parallel wall time is not < 70% of serial sum.')\n  process.exit(1)\n}\n```\n\nThat last block is deliberate, and it's worth keeping in your own version. It's a **parallelism self-check**: if the three calls didn't substantially overlap — say your provider rate-limited you and quietly serialized the requests — the wall time creeps up toward the serial sum and the script exits non-zero. So if you run this and see `ASSERTION FAILED`\n\n, that's usually not a bug in the code; it's the check earning its keep by telling you the fan-out degraded into a queue.\n\nOn a real run against DeepSeek the three specialists overlapped for a **2.21× speedup** — 11.7s of wall time against 25.9s of summed per-agent work. The exact number moves with model latency and network, which is the point of measuring it per run instead of quoting a brochure figure.\n\nFan-out gets you three results in parallel. You still need them merged into one report — and that's a fourth agent, running *after* the others because it depends on all three. No hiding it: this pattern is three-parallel-plus-one, not three.\n\nThe aggregator takes the prose summary as text and the two structured results as JSON, and is told to emit a fixed four-heading report:\n\n``` js\nconst aggregatorPrompt = `Merge the three analyses below into a single Markdown report.\n\n--- SUMMARY (prose) ---\n${byName.get('summary')!.output}\n\n--- ACTION ITEMS (JSON) ---\n${JSON.stringify(actionData, null, 2)}\n\n--- SENTIMENT (JSON) ---\n${JSON.stringify(sentimentData, null, 2)}\n\nProduce the Markdown report per the system instructions.`\n\nconst reportResult = await pool.run('aggregator', aggregatorPrompt)\n```\n\nIts system prompt pins the output structure (`## Summary / ## Action Items / ## Sentiment / ## Next Steps`\n\n, action items as a table) and adds one important rule: *do not invent action items that are not grounded in the other data.* The aggregator's job is to format and synthesize next steps, not to discover new facts — that line keeps it from drifting.\n\nThe example ships with `claude-sonnet-4-6`\n\n; these numbers are from a run swapped to DeepSeek (`deepseek-v4-flash`\n\n) — the agent configs are identical, only the model id changes. The three specialists fanned out, the `action-items`\n\nand `sentiment`\n\noutputs validated against their Zod schemas, and the aggregator produced the report above. Token usage for the full run — three specialists plus the aggregator — was **3,225 input and 4,083 output tokens**. (That's token counts, not a dollar figure; what you pay depends on your provider and model.)\n\nA thing to set expectations on: fan-out buys you **wall-clock time, not tokens.** You still make four model calls — you've just stopped waiting for them one after another. And you added a call (the aggregator) you wouldn't have with a single prompt. On a tiny transcript the coordination overhead can eat the win; the pattern pays off as each specialist's own work grows.\n\n**Reach for fan-out when** one input needs several independent analyses. Meeting → {summary, actions, sentiment} is the canonical case, but so is a PR → {security review, style review, test-coverage check}, or a support ticket → {category, urgency, suggested reply}. Independent jobs, same source, typed outputs you want to use downstream.\n\n**Don't** when the steps depend on each other — research-then-write is a pipeline, not a fan-out, and forcing it parallel just breaks the data flow. And don't fan out a single job for the sake of it: one agent is simpler than a pool plus an aggregator.\n\nThere's also a higher-level option in the same framework. Here you wired the parallelism by hand — you decided what runs concurrently. If you'd rather describe a goal and let a coordinator decompose it into a task graph and parallelize *that* for you, that's what `runTeam()`\n\ndoes; I wrote it up in [Goal In, DAG Out](https://dev.to/jackchenme/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag-1n0m). Hand-wired fan-out like this post is the right call when the shape is fixed and you want it explicit; the coordinator is the right call when the shape varies with the goal.\n\n```\nnpm install @open-multi-agent/core\n```\n\nThe full example is in the repo — run it from the repository root (it needs `ANTHROPIC_API_KEY`\n\n):\n\n```\nnpx tsx packages/core/examples/cookbook/meeting-summarizer.ts\n```\n\nSource to read: the [ meeting-summarizer example](https://github.com/open-multi-agent/open-multi-agent/blob/main/packages/core/examples/cookbook/meeting-summarizer.ts) and its\n\n`fan-out-aggregate`\n\npatternOne honest caveat: the transcript here is a synthetic standup, and the project's production validation is still early. If you point this at real meetings, I'd like to hear where the typed extraction held up and where it didn't.", "url": "https://wpnews.pro/news/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript", "canonical_source": "https://dev.to/jackchenme/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript-3oe", "published_at": "2026-06-24 11:34:38+00:00", "updated_at": "2026-06-24 11:39:38.933247+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "ai-agents"], "entities": ["open-multi-agent", "Claude Sonnet", "TypeScript", "Zod"], "alternates": {"html": "https://wpnews.pro/news/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript", "markdown": "https://wpnews.pro/news/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript.md", "text": "https://wpnews.pro/news/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript.txt", "jsonld": "https://wpnews.pro/news/from-transcript-to-typed-action-items-three-parallel-agents-in-typescript.jsonld"}}