OCRAgent started as an n8n workflow. It grabbed documents from inboxes, ran OCR and compared information between the files. That gave me a useful first version of the idea, but the scope changed as I began thinking about a product for other companies.
After the conversation with Jawad Zoumi of TEDI Services, I rebuilt the application from scratch. I tried to organize it around hexagonal architecture. Later, sudden changes in requirements pushed me toward another question: what should stay in the core, and what should belong to a specific workflow?
What I wanted from hexagonal architecture
My aim was to give the central application a clearer boundary. Document-processing logic should not have to know every detail of an inbox connection, a storage service or a particular destination system. Those connections should have explicit interfaces.
That is the architectural intention behind the rebuild. The label by itself proves little. What matters is whether the boundaries make a new requirement easier to implement and test without accidentally changing unrelated behavior.
Changing requirements exposed the next problem
A request for three-way matching is different from a request for import-document checks. ERP insertion introduces another set of questions. Email automation introduces recipients, proposed content and authorization to send.
If I treated those as small variations of one universal flow, I would keep adding conditions to central logic. I wanted a structure where the shared work could remain recognizable while each operational workflow owned its own decisions.
The core should handle the common document work
The common foundation concerns the identity of a case, its source documents, extracted information and supporting evidence. It also needs to represent processing progress and failure clearly. These are useful concerns across several document applications.
An inbox adapter should be responsible for its intake connection. A reading provider should have a defined contract. A destination integration should have its own delivery boundary. The architecture series describes how the repository separates several of these responsibilities.
A workflow plugin should express a particular problem
In the plugin direction I am pursuing, three-way matching concerns orders, accepted receipts and invoices. Import checks concern the documents and references required for that dossier. Their document vocabulary and comparison rules differ.
ERP insertion or document-based email automation may also require adapters and application steps around a plugin. Calling everything a plugin would hide those responsibilities. The useful principle is to keep workflow rules separate from reading documents and performing external actions.
What is documented, and what remains a direction
The public OCRAgent repository describes Ironclad OCR, an import-dossier pilot and an earlier invoice workflow. It includes provider and workflow contracts, source evidence and review actions. Those implemented paths are different from a promise that every proposed integration is complete.
Inspect the OCRAgent repository
When I talk about supporting another ERP or automating email, I am describing a scope to investigate and implement with its own access and acceptance tests. Reusing a core should reduce duplicated work; it should not conceal the work a new workflow still needs.
The reviewer belongs in the design
An illustrative comparison can identify an invoice quantity that differs from an accepted receipt. It cannot decide which evidence the organization should recognize or who may approve the exception. Those are workflow rules and permissions.
I want the system to present what it found and let the authorized person resolve the case. That boundary also applies to external actions: preparing reviewed information is different from silently writing it into an ERP or sending an email.
Why this architecture matters to Kaliits
Kaliits is the commercial home for discussing these document workflows. OCRAgent is where I make the underlying engineering inspectable. The shared-core idea connects them: a reusable foundation, with the customer's actual process determining the rules and integrations.
The test of the architecture is practical. Can I add a bounded workflow, explain its behavior, handle its exceptions and hand it over responsibly? That is the result I want the structure to support.