The AI in Rixoffice is not a single text box bolted onto the side of an editor. It is a small team of agents that reads your file, decides what to do, calls app-specific tools and reports back while you keep working. The design goal is simple to state: you describe an outcome in plain language, and the system does the reading, planning and editing against the real structure of your file — not a guessed copy of it. This page explains how that team operates, how it keeps edits surgical, and how the pieces fit together across RixDocs, RixSheets, RixSlides, the PDF Editor and Markdown Studio.
AI that works at the block level
Rixoffice represents every file as a set of blocks. In a document, a heading, a paragraph, a table row or a single table cell is a block. In a workbook, a range of cells is a block. In a deck, each slide element is a block. Agents address blocks individually, which changes what AI editing feels like in two concrete ways:
- Surgical edits. Ask the agent to rewrite one paragraph and only that paragraph changes. Your styles, the rest of the table and every other page stay exactly as they were. There is no regeneration of surrounding content, no drift in formatting and no need to re-read the document after a small fix.
- Real-time agent syncing. As an agent works, its changes land in the editor live, block by block. You watch a table appear or a section tighten in real time instead of staring at a progress spinner and hoping for the best.
The block model is also the safety mechanism. Because every tool operates on a named target, the AI cannot quietly rewrite content you never asked about. This is why AI in Rixoffice feels like a careful colleague with a fine-tip pen rather than a blunt instrument that regenerates your whole file for a one-line change.
The agent loop behind the composer
The runtime that powers all of this is called agent-core. It implements a ReAct-style agent loop: the model reasons about your request, acts by calling a tool, observes the result, then reasons again until the task is complete. The loop is what lets an agent handle multi-step work without you scripting the steps yourself.
A typical loop for a request like "add a comparison table after the intro" looks like this:
- Reason: the agent loads the document context and decides it needs the docx skill.
- Act: it calls a tool to locate the intro heading and confirm the insertion point.
- Observe: the tool returns the surrounding block structure, including the styles in use.
- Act: it calls insert_content with the new table, targeting the confirmed position.
- Observe: the tool confirms the block was written, and the table appears in your document in real time.
Because every action goes through a tool, the agent works against the actual structure of your file. It cannot invent a heading that is not there; it has to look, find the real anchor and attach its work to it.
Multi-agent orchestration with delegation
Simple requests finish in one loop. Bigger jobs are split across agents. The orchestrator hands subtasks to specialists using the agent_delegate tool, and every delegation carries a budget that caps how much work the subtask may consume before it must stop and report back.
The budget is what keeps large jobs bounded and predictable. A request such as "review the whole report and fix the weak sections" could, in a naive system, run for an unbounded amount of time and cost. Here it is split, delegated with sensible limits, collected and summarized: the orchestrator tells you exactly what changed, what was attempted and what, if anything, was left unfinished when a budget ran out. Delegation is also how quality emerges — one agent builds, another reviews the build.
The five-agent roster
Five agents cover the division of labor:
| Agent | Role | Typical job |
|---|---|---|
| Sisyphus | Orchestrator | Runs by default; routes your request and delegates |
| Hephaestus | Executor | Performs the actual edits and builds |
| Prometheus | Planner | Outlines long or complex work before execution |
| Momus | Reviewer | Critiques results and requests fixes |
| Oracle | Read-only analyst | Answers questions without changing anything |
Sisyphus runs by default, so you never have to pick an agent to get started — routing happens behind the composer. Each agent has its own page in the agent roster, including the logic the orchestrator uses when choosing one over another.
What you can ask an agent
The composer understands plain language, and the same phrasing works in every app:
- Rewrite this paragraph to be more concise.
- Summarize the selected section in three bullet points.
- Find every table in this document and flag rows where the total does not add up.
- Draft an outline for a ten-page proposal on this topic.
- What does this formula do, and is the range correct?
Notice the pattern: the best requests state an outcome rather than just an action. "Fix the introduction so it states the main claim in one sentence" gives the planner something to aim at and the reviewer something to verify against.
Where you meet the agents
Every app talks to the same agents through the same composer, with a tailored toolset per app:
- In RixDocs, agents rewrite paragraphs, rebuild tables and apply formatting commands.
- In RixSheets, they read ranges, propose cell operations and explain formulas.
- In RixSlides, they plan decks, write slide scripts and generate full presentations.
- In the PDF Editor, they search pages, summarize, mark up and edit text.
- In Markdown Studio, they draft and refine blocks alongside your writing.
Each app exposes its own set of tools — the skills — so the agents always have the right hands for the file in front of you. The per-app toolsets are documented in agent skills.
What agents will not do
The loop is designed to keep you in control. Changes are previewed before they are applied wherever an edit is destructive, and a whole-document rewrite in RixDocs always asks for confirmation first. Oracle is read-only by design and cannot modify your file. Delegated subtasks stop when their budget is spent, and the orchestrator reports what was completed and what was left out. Nothing happens silently behind your back — the editor shows the work as it happens, block by block.
What to explore next
- The agent roster — meet Sisyphus, Hephaestus, Prometheus, Momus and Oracle in detail.
- Agent skills — the exact tools each app hands to the agents.
- AI credits explained — what an agent action costs on built-in Rix AI.