Technical analysis, a merger desk and an IPO diligence rubric are live
Pi Terminal
Sign in
Research workflows

Build the work once, and have it rest on the same evidence every quarterBuild the work once, and have it rest on the same evidence every quarter

A saved prompt asks a model to choose its own tools, so the same playbook run twice can rest on different evidence. A built workflow fixes it, and that is the whole difference.

Request accessOpen the workflow builder
Press run. Three tool steps in milliseconds, one ask step that takes a model's time.
Consolidation screen4 steps0 of 4
  1. 1capital_pressurethreshold 5,000,000,00010 banks below the bar · smallest shortfall 851m · 2 do not report capital
  2. 2merger_combineZemen Bank + Enat Bank115.8bn combined assets · rank 9 and 19 become 7 of 26
  3. 3peer_comparisoncompany: Zemen BankTotal assets 9 of 27 · ranked on reported absolutes only
  4. 4Write the committee notefrom the evidence above, nothing elseTen banks report less than five billion birr of paid-up capital. Zemen and Enat combine to 115.8bn of assets, moving from 9th and 19th to 7th of 26…

The three tool steps return the same figures on every run. Only the last step asks a model, and it writes from what they found.Tool steps read the terminal directly. Press run.

Live, on figures read out of the terminal's cache on 2026-10-04, each carrying the year it was reported.

What it does

  • Thirteen tools, composedTechnicals, peer panels, capital pressure, merger combinations, cross-entity links, the treasury tape, macro series and more — each a step with arguments you choose.
  • A model only where one is neededTool steps run with no model in the loop. An ask step then writes over what they gathered, and is told to quote their figures rather than produce its own.
  • A run you can rereadEvery run is kept with each step's input, output, citations and timing, and exports as a document you can check a quarter later against the figures it rested on.
  • Shared, with a barrierA workflow can be private, shared to an email, or visible to the firm. A run belongs to whoever ran it, whatever the workflow's visibility.

What it refuses

On a market this thin the refusals are the product. Anything that fills a gap quietly is the thing you would have to check by hand anyway.

  • A step naming a tool that no longer existsRefused when the workflow is saved, with the list of tools that do exist — not discovered by whoever runs it next quarter.
  • An unbounded runTwelve steps, at most four of which may ask a model. Past that it belongs in code, and the limit keeps one saved workflow from becoming an open bill.
  • A failure that throws the run awayA refused step is recorded as a refusal with its reason and the rest carries on. A workflow that gathered six of seven things is worth more than an error page.
Reads from
  • The terminal's own tool catalogue