The work isn't done when the answer is.

Nobody sends a chat transcript to a client

Most platformsThe run ends with text in a scroll. It may be excellent text — but between that and the thing you actually needed sits an hour of copying into slides, fixing headings, rebuilding a table, and hunting for the chart that was described in prose but never drawn.

orqoAn agent doesn't write a description of a report. It builds the report — titled, sectioned, with tables, statistics, charts and covers as real elements — and what comes back is the file you were going to make by hand.

The geometry decides what it is

This is the one choice that is yours: ask for a flow document, a portrait report at letter or A4, or a landscape deck at 16:9. One engine renders all three — the geometry is what changes.

Nine layouts, twenty-three elements

…and growing.

That sounds small until you see that it stacks. A layout exposes slots; a slot takes an element that fits it — or another whole layout, nested inside. Nine and twenty-three combine into far more distinct pages than either number suggests, which is exactly the point: the range comes from the composition, not from a long catalogue anyone has to maintain.

None of this is yours to manage. You choose the shape — flow, letter, 16:9 — and that is the whole of it. Inside it there is no template to pick and no grid to fight: this is the machinery that makes the output good without asking anything more of you. The agent chooses a handful of things; the stacking supplies the variety.

And the constraint is what makes it work. A model composing freely on an open canvas produces the overlapping, overflowing slides everyone has seen. A model choosing from a vocabulary where every piece already fits produces pages that hold together. The catalogue it validates against is generated from the renderer itself, so what an agent is told it can build and what will actually render cannot drift apart.

The agent looks at what it made

A language model writing a deck is working blind — it emits a structure and never sees the slide. That is why AI decks so often have text running off the edge, an empty panel, a chart that didn't fit.

Here the agent can render its own draft to an image and look at it, mid-run, before you ever do. Overview the whole deck, or open one slide at full detail. It sees the overflow, sees the empty half, and fixes it — the same loop a person uses when they glance at a slide and notice it's wrong.

That closes the gap between a structure that is technically valid and a page that is actually presentable. How a stage runs

Set four colours, not forty

You define a background, a title colour, a body colour and an accent — light and dark variants of each — plus a heading font, a body font and your logo. The renderer derives the rest of the palette from those four and picks the light or dark variant automatically, based on how dark the piece itself is.

It inherits the way you'd expect: your organization sets the default, a workflow can override it for the work it produces, and any single artifact can override that — so the one deck going to a particular client can look however it needs to without disturbing anything else.

And it stays editable after the fact. Open a finished artifact, change the colours or the type scale, and it re-renders in front of you — no re-running the workflow, no paying for the work twice. The version you send is the version you looked at.

A PowerPoint you can open and change

Export a deck and you get a real .pptx — one native slide per slide, with editable text boxes, native tables, real pictures and shape fills. Not slides rasterised into images, which is what "export to PowerPoint" usually means and which nobody can edit.

It stays honest to what you saw because of how it's built: the deck is composed once, rendered in a real browser, and every element's actual position and style is measured off that render before being written out as a native PowerPoint construct. The exported geometry cannot drift from the one on your screen, because it is read from it.

PDF works for every shape — documents, reports and decks alike. Editable Word export is not available yet; it needs a new exporter built against the current element model rather than the retired one, and is on the list rather than in the product.

What you see is what exports

The interactive version on screen, the PDF, the PowerPoint and the image the agent reviewed all come out of a single composition engine.

That is an architectural choice with a practical payoff: there is no second renderer to fall behind the first. A layout that looks right in the run view cannot quietly export broken, and the agent's visual check is a check of the real thing rather than an approximation of it.

A document that doesn't dead-end

Finished output is usually the end of the line. Here it is also an input.

A finished document is the default, not the only ending

Plenty of work doesn't want a report at the end of it. It wants a message in the channel the team already watches, or a row written back into the system the business actually runs on.

A workflow's exit can deliver instead of render: post the summary to Slack, send it as mail, reply on WhatsApp or Telegram, fire a webhook, drop the file where your files live, or write the result straight into the record it belongs to — a CRM, a project tracker, an ERP, a database. The same run can do several: file the deck, message the channel, update the record.

And it isn't limited to a catalogue. If the connector doesn't exist, orqo's Integration Builder researches the API and builds it — so "deliver it into that" is a description you write, not a roadmap item you wait for. How integrations get built  ·  Exit hooks and stages