The agent-first approach
The problem
The accounting of a small or mid-sized business involves dozens of concepts (journals, PCG accounts, VAT, lettering, bank reconciliation, provisions, year-end closing…) and complex flows with strict dependencies.
A traditional accounting software exposes this complexity through menus and forms. The user has to know where to go and what to do — which assumes accounting expertise that the managers of very small and small businesses generally do not have.
The solution: the agent as navigator
The user speaks in natural language:
“I uploaded my January invoices, what’s left for me to do?”
The agent diagnoses the state of your accounting, proposes an action plan, executes it through the specialized tools, and delegates to the sub-agents when the task requires it.
The user does not need to navigate through menus.
Why it works for accounting
The complexity is in the orchestration
Qualifying an invoice is not hard: it is a rate and a VAT box. The complexity lies elsewhere:
- knowing when to qualify;
- knowing how to handle special cases;
- knowing in what order to act relative to the other stages.
An agent that knows the procedures and the state of the workflow navigates this complexity naturally.
The questions are contextual
The agent asks the right questions at the right moment. At upload: “Supplier or credit note?”. At qualification: “Meal alone or business meal?”. At bank reconciliation: “Which invoice does this transfer correspond to?”.
The agent learns
Through pattern learning, the questions become rarer with use. A supplier qualified once is qualified automatically the following times.
The role of the UI
The graphical interface complements the agent:
- Dashboards — KPIs, charts, balances
- MDX views — custom reports built by the agent at your request
- Resolution forms — when a block requires structured input
- Documentary navigation — browse documents, journal entries, third parties
The UI is built as a client of the same tools as the agent (via MCP symmetry), not as a standalone application.
The trade-offs
Dependence on the AI model
If the model is unavailable, the user is limited to the UI. Simon supports several providers and the UI can perform the same operations autonomously.
Cost
Each interaction consumes tokens. The cost varies depending on the provider, the model, the volume of documents and the length of the context. Simon limits consumption with structured procedures and prompt caching when the provider allows it, but prices must be checked in the chosen provider’s pricing grid.
Reversed learning curve
It is not the user who learns the menus — it is the agent who learns the context. The first interactions are longer, but the system speeds up with use.