Inside Accounting AI Agent: one agent, 80+ tools, and real wFirma data

In our product article we've already covered what Accounting AI Agent can do: it answers VAT, PIT, and CIT questions, works with your real invoices in wFirma, and automates the routine. That was the user's-eye view. Now let's come at it from the other side — the implementation side — and see how it all works inside.

Accounting in Poland means constantly shifting rates, deadlines, and requirements, and the cost of a mistake is measured in real money and penalties. A generic chatbot is dangerous here: it will confidently name a deadline that doesn't exist, invent an account number, or «recall» last year's rate — and it all sounds convincing. We built the system so it has as few reasons to make things up as possible: the agent doesn't guess from memory, it reaches for live data — your invoices in wFirma, Polish state registries, the official tax-deadline calendar. In this article we walk the whole path: from the overall map of the system to which model handles which task. Along the way — every key diagram, tidied up for a reader rather than an engineer.

One idea runs through the whole text: the strength of this product is not the size of the model but the discipline around it — the tools, the checks, and the tie to real data. That's where we start.

How the whole system is built

Before diving into details, it helps to see the map. Accounting AI Agent is a full-fledged web application (not a «wrapper around ChatGPT»): it has a browser dashboard, a Telegram bot, a server with access control and validation, an integration layer to the outside world, and databases.

flowchart TB
  subgraph Clients["How users reach the agent"]
    WEB["Web app<br/>(Next.js)"]
    TG["Telegram bot"]
  end
  subgraph Core["Server & AI"]
    API["Server (API)<br/>auth · permissions · checks"]
    AGENT["AI agent<br/>(single, on LangGraph)"]
    OCR["Receipt OCR<br/>(GPT-4o vision)"]
  end
  subgraph Integrations["Integrations with the outside world"]
    WF["wFirma<br/>invoices · company · payments"]
    KSEF["KSeF<br/>government e-invoices — FA(3)"]
    REG["Polish registries<br/>Biała Lista MF · KRS"]
  end
  subgraph Data["Storage"]
    PG["PostgreSQL<br/>data · AI memory"]
    RED["Redis<br/>sessions · limits"]
  end
  WEB --> API
  TG --> API
  TG --> OCR
  API --> AGENT
  AGENT --> WF
  AGENT --> KSEF
  AGENT --> REG
  API --> PG
  API --> RED
  WF --> PG

On the left are the ways in: a browser dashboard and a Telegram bot. In the centre is the server, responsible for login, permissions, and data validation, and the AI agent itself. On the right is the outside world: wFirma (the accounting platform), KSeF (the government e-invoice system), and Polish public registries. At the bottom are the stores: PostgreSQL for data and the agent's long-term memory, Redis for sessions and rate limiting. Next we go through each large block in turn.

A single agent, not a «swarm»

It's fashionable now to build «teams» of many AI agents that hand tasks to one another. We deliberately went the other way: we have one agent. It receives the message, decides for itself which tools to call, invokes them one by one or several at once as needed, and then composes the final answer. There is no «dispatcher» routing requests between sub-agents — this is simpler, more predictable, and cheaper to debug.

It works on the classic «reason → act» loop: the model looks at the message and the history, decides whether a tool is needed, calls it, gets the result — and the loop repeats until the final answer is ready.

stateDiagram-v2
  state "AI agent (model)" as A
  state "Tools" as T
  [*] --> A: user message
  A --> C: model response
  state C <<choice>>
  C --> T: has tool calls
  C --> [*]: final answer (no calls)
  T --> A: results appended to the dialogue
  note right of A
    The model with
    bound tools
  end note
  note right of T
    Tools run and return
    data from wFirma,
    KSeF and registries
  end note

So the agent doesn't «spin» in endless tool calls, there is a hard fuse — no more than 25 steps per request. In practice that is more than enough even for complex scenarios like «find the contractor and issue them an invoice», while reliably guarding against loops.

The path of a single message

What exactly happens between «the user hit send» and «the answer arrived»? The order of steps matters, so let's show it in full.

flowchart TB
  A["User sends a message"] --> B["Take the user's<br/>model API key"]
  B --> C["Create the model<br/>(OpenAI or Google Gemini)"]
  C --> D["Detect language<br/>from the text (ru / pl / en)"]
  D --> E["Load long-term memory<br/>about the user's business"]
  E --> F["Build the system prompt<br/>role + language + rules + tax + memory"]
  F --> G["Bind the tools<br/>58, up to 82 with HR and KSeF"]
  G --> H["Run the agent<br/>(reason — tools loop)"]
  H --> I["Save the conversation"]
  I --> J["Update memory<br/>(in the background)"]
  I --> K["Voice the answer<br/>(background, optional)"]

Notice the two «background» steps at the end. Once the answer has been sent to the user, the system — without holding them up — updates the long-term memory and, if needed, prepares the voicing. In other words, the user doesn't wait for all the housekeeping to finish; they get the answer right away.

58 tools, and up to 82 with HR and KSeF

All of the agent's «power» is in its tools. A tool is a specific ability: «get the list of invoices», «create a contractor», «calculate payroll», «send an invoice to KSeF». The model doesn't perform these actions itself — it only decides which tool to call and with what parameters, and vetted code does the work.

flowchart LR
  AGENT(["The AI agent picks the tools it needs"])
  subgraph BASE["Always available — 58 tools"]
    direction TB
    T1["Company & contractors<br/>lookup by NIP, registries"]
    T2["Invoices & sales<br/>create · send · PDF"]
    T3["Payments & expenses"]
    T4["Taxes: KPiR · JPK_VAT · PIT"]
    T5["Tax-deadline calendar"]
    T6["Bank-account White List (Biała Lista)"]
    T7["Documents · ledgers · vehicles · terms"]
  end
  subgraph OPT["Enabled when configured"]
    direction TB
    HR["HR & payroll — 15"]
    KS["KSeF — 9"]
  end
  AGENT --> BASE
  AGENT -.-> OPT

The base 58 tools are there for every user. Two more sets — 15 for HR and payroll and 9 for KSeF — are enabled automatically if the corresponding capabilities are set up. That's up to 82 tools in a single agent's hands. Importantly, some tools don't depend on wFirma at all and are available to everyone, always: for example, the tax-deadline calendar and the White List contractor check.

Answers on real data, not off the top of the head

This is the key difference from a «smart but hallucinating» chatbot. When a question touches specifics — your company, a contractor, an amount — the agent goes to reliable sources for the data instead of inventing it.

flowchart LR
  Q["User's question<br/>or action"] --> AGENT["AI agent"]
  AGENT --> WF["wFirma<br/>real invoices, company,<br/>payments, expenses"]
  AGENT --> REG["Public registries<br/>Biała Lista MF · KRS"]
  REG --> AF["Autofill by NIP<br/>name · REGON · address"]
  AGENT --> WL{"Payment ≥ 15,000 zł?"}
  WL -->|yes| CHK["Verify the account against<br/>the MF White List (mandatory)"]
  WL -->|no| SKIP["Ordinary record"]
  WF --> ANS["Answer on real data<br/>+ official links"]
  CHK --> ANS
  AF --> ANS

A couple of details that save time and nerves:

Autofill by NIP. Give just one tax number for a contractor, and the system pulls the missing name, REGON, and address from the public registries (the Ministry of Finance's Biała Lista and KRS) and shows you which fields it filled in automatically.

The «White List» check. For any payment of 15,000 zł or more, Polish law (Art. 117ba of the Tax Ordinance) requires you to confirm that the contractor's account is on the official Ministry of Finance «White List». The agent is explicitly instructed to run this check automatically when you make a large payment — so you don't lose the right to book the expense over a formality.

KSeF: e-invoicing, government-style

With Poland's move to the mandatory KSeF e-invoice system, businesses gained a new routine. The agent takes it on: it can generate a structured invoice in the required format (FA(3)), send it to KSeF, wait for official confirmation, and match incoming invoices to your records.

flowchart LR
  A["Invoice from chat<br/>or from wFirma"] --> GEN["Generate<br/>FA(3) XML"]
  GEN --> SEND["Send to KSeF"]
  SEND --> POLL["Status check<br/>in background (every minute)"]
  POLL --> UPO["UPO — official<br/>confirmation"]
  subgraph Incoming["Incoming"]
    IN["E-invoices from KSeF"] --> MATCH["Match against<br/>wFirma records"]
  end

Separate background services watch the statuses of already-sent invoices and, if configured, send new invoices created in wFirma to KSeF by themselves. And when you create an invoice right in the chat, it's enough to name the company — the system fills in the missing NIP and address from the local contractor database.

A receipt from a photo

Another way to cut out manual entry is simply to photograph the receipt. The user sends a photo in Telegram, and the system recognises it before the AI agent even gets involved.

flowchart LR
  P["Receipt photo<br/>in Telegram"] --> OCR["Recognition<br/>(GPT-4o vision)"]
  OCR --> CARD["Structured card:<br/>seller · amount · date · NIP"]
  CARD --> EXP["Create an expense in wFirma<br/>(contractor auto-filled by NIP)"]
  N["A separate step in the photo handler,<br/>before the AI agent"] -.-> OCR

Recognition is handled by the GPT-4o model with image support. It picks the answer's language from your Telegram account's language, and returns the result as a tidy card from which an expense is booked into wFirma in a single step.

Long-term memory of your business

A good assistant doesn't ask the same thing twice. So the agent has a long-term memory: it remembers facts about your company, frequent contractors, and your preferences — and takes them into account in later conversations. And the memory is arranged carefully and predictably.

flowchart TB
  subgraph Extract["Extraction (background, after the answer)"]
    R["Answer produced"] --> RULES["Parse by rules and patterns<br/>no LLM: «my company…», «always…»"]
    RULES --> USE["Track frequent tools<br/>and contractors"]
  end
  subgraph Store["Storage (PostgreSQL)"]
    M[("Memory: business facts ·<br/>frequent contacts · preferences ·<br/>workflow patterns")]
  end
  subgraph Decay["Decay (lazy, once a day)"]
    DEC["Not recalled for 30 days →<br/>lower the confidence"] --> HIDE["Confidence too low →<br/>fact is hidden"]
  end
  subgraph Inject["Injection into the prompt"]
    TOP["Take up to 20 most important<br/>(budget ~6000 chars)"] --> SP["Add to the system prompt<br/>of the next conversation"]
  end
  USE --> M
  RULES --> M
  M --> DEC
  M --> TOP

There's a non-obvious but important detail here: the memory is filled not by a separate AI model but by deterministic rules. The system looks in the conversation for explicit markers («my company is on the 19% flat tax», «always invoice in PLN») and notes frequently used contractors and operations. This is cheap, fast, and doesn't add yet another reason to hallucinate.

The memory is sorted into clear categories — business facts, frequent contacts, preferences, and workflow patterns — and doesn't grow unchecked: whatever hasn't been useful for a long time gradually «decays» and is hidden, and only a couple of dozen of the most important records are inserted into the prompt, within a strict character budget. That keeps the context relevant and the model costs under control.

The system prompt and language

The system prompt is the instruction the agent receives before every conversation. It isn't static: the system assembles it from layers tailored to the specific request — the base role of an accounting expert, language rules, tool guidance, response-formatting rules, professional standards and disclaimers, accuracy requirements, error handling, and, when needed, current Polish tax data and personal memory.

The system detects the language automatically from the message itself: Cyrillic — we answer in Russian; Polish diacritics — in Polish; otherwise — in English. From there every tool returns its result already in the right language, with the number, date, and amount formatting familiar in that particular country.

Your keys, your choice of model

An important feature of the architecture: the keys to the language models belong to the user. Each person connects their own key (stored encrypted in the database), and the system works on top of it. Two providers are supported — OpenAI and Google Gemini. The newer OpenAI models (the gpt-5, o1, o3 families) are handled by their own special rules — for example, the «temperature» parameter isn't forced on them.

By the way, there's no Anthropic support here any more: in the spring of 2026 we removed it — it lingered only as a leftover of old multi-agent code and one more reason to keep yet another paid key. Fewer dependencies means a cleaner architecture.

The project itself is open on GitHub, and the whole stack can be run on your own infrastructure: your own server, your own keys, full control over the data. And for those who want ready managed hosting, there's a subscription at eKsiegowyAi.pl. Security wasn't forgotten either: token-based login, password hashing, request rate limiting, validation of all inputs and protection against database injection, and every mutating operation is written to an audit log.

Conclusion

Put it all together and a simple thought emerges: a reliable accounting assistant comes not from «a bigger model» but from careful engineering around it. One clear agent instead of a tangled swarm. Dozens of vetted tools instead of guesswork. Live data from wFirma and the state registries instead of «knowledge off the top of the head». Mandatory checks where the law requires them. Predictable, rule-based memory. And keys that stay with the user.

It's exactly this discipline that turns a talkative model into a tool you can trust with the routine — and still sleep soundly, knowing it won't invent an account number for you. You can try Accounting AI Agent at eKsiegowyAi.pl or build it yourself from the sources on GitHub. And if you need a similar agent embedded into your own systems and data, write to us: [email protected].

Which model does what

Finally — a summary of which model handles which task. One thing to underline separately: filling the long-term memory works without a language model, on deterministic rules, so it isn't in the table.