An agent isn't a chatbot. It's a digital colleague with a clearly defined job.
We build an agent that can read a document, decide based on your rules, and hand things over to a person wherever judgment is needed. But it only works when it has a precisely defined role, input, output, and guardrails. That's exactly what we do — and here we show how.
What an AI agent actually is — and how it differs from ordinary automation
Automation runs on a fixed track: when X arrives, do Y. Great for things that never change. An agent is given a goal and context and decides for itself which steps lead there — it reads a document, finds a similarity, holds a conversation, and when something is beyond it, it escalates to a person. That's the difference between a script and a digital colleague.
Automation = a fixed track
A fixed procedure, no decision-making. When an invoice arrives in the expected format, it gets transcribed into the system. Reliable, cheap, but blind to the exception. A different layout and it stalls.
Agent = a goal plus judgment
We tell it "create the line items in the ERP from this order" and it copes even with the fact that every customer writes their email differently. It understands content, not just format. Our email-to-order agent doesn't read a form — it understands the order.
Why it matters to a decision-maker
An agent can handle processes that used to require a person, because they involved judgment over text and documents. That's exactly the expensive, exhausting routine that couldn't be "scripted" — and where time and know-how are leaking today.
It's not magic, it's engineering
An agent works reliably only when it has a properly crafted framework: a role, inputs, outputs, rules, integrations, and metrics. Without those it's a flashy demo that collapses in real operation. We build the first kind.
What a reliable agent is made of — step by step
This is the core of the whole job. An agent isn't one "smart model" but a system of clearly defined components. Leave any one of them out and the agent won't run for you long-term — which is why it isn't cheap work, but a project with weight. This is how we build it.
Role — what it does and what it does NOT
First we precisely describe the process and its dependencies, then the agent's role. "Load the top-level item, read the title block and bill of materials, create the component structure." And just as important: what it should not do. The boundary of the role is half of reliability.
Input and output at every step
What the agent receives (a PDF drawing, an email, a query) and what exactly it returns (rows into the ERP, a draft reply, a CSV to import). A clear input and output means the result can be checked and measured — not just "it somehow runs".
Rules and guardrails — may / may not
What the agent is authorized to do on its own and where it must stop. Guardrails aren't an extra constraint, they're the rails that make the agent trustworthy. Without them you'll never give an agent access to a live ERP.
Tools and integrations — the agent's hands
An agent only makes sense when it's connected to the reality of the company. We connect it to the ERP (K2, Helios, Business Central), SharePoint, M365, CRM, PDM/CAD, email, WhatsApp — via API as well as RPA where there's no API. A central data layer as the nervous system over which the agents work.
Memory and context — RAG
So the agent can answer over company data, we consolidate documents from the ERP/SharePoint/DMS/NAS into a vector database (Qdrant, Weaviate, pgvector). Scanned and PDF documents go through OCR (ABBYY, Tesseract). The agent then answers from the company's context — and always with a source.
Human-in-the-loop — where the person decides
The agent recommends, the person approves. We define the exact points where work is handed over: the process engineer fine-tunes what only they can see from the drawing; the sign-off is done by a person, not a machine. This is the difference between a trustworthy tool and a black box.
Metrics — what it's evaluated by
Error rate, response time, how much work it saves, how adoption grows. An agent isn't deployed and forgotten — it's evaluated and tuned. Without a baseline and a defined benefit, no agent gets built here.
Governance and security from the start
Rules for what may and may not go into AI (the AI traffic light), who owns it, how data is accessed. For sensitive data, private AI on your own infrastructure (on-prem, local Llama/LLaVA, NVIDIA stack). Security is part of the design, not an add-on at the end.
What the agent does not do: it doesn't send anything outside the company without approval. It doesn't delete data. It doesn't decide about money — approvals stay with people. It doesn't train on your data for anyone else.
The technology under the hood
What agents in our practice can really do
These aren't abstract categories from a slide deck. We have each type built in a real project. We choose the model and the tool based on the task and the sensitivity of the data — Claude, GPT, Gemini, Copilot, Azure OpenAI, or a local model — not based on fashion.
Reading / extraction agent
Reads a PDF drawing, a title block, a bill of materials, an invoice, a contract, and extracts structured data from them. The foundation for engineering shops as well as for extracting from attachments.
Email agent
An order arrives by email, the agent extracts the line items from it and creates it in the ERP — instead of transcribing it by hand, item by item. It can also draft replies to recurring queries.
Knowledge / RAG agent
Answers over company documentation in natural language and always shows the source. Service know-how that used to leave with the technicians stays in the company.
Process agent
Turns a meeting transcript into tasks and escalations. A self-service skill that every employee can run themselves, not just IT.
Reporting agent
Data from the ERP or data warehouse in natural language. Instead of clicking through exports, a salesperson asks and gets a filtered answer.
Communication agent / chatbot
Web, WhatsApp, 24/7. Handles an inquiry, filters the mail, answers a recurring query, and sends the rest to a person.
How we build an agent you can trust
Reliability isn't a promise, it's a way of working. An honest agent knows how to say "I don't know this" and how to say "I'll leave this to a person". Knowing where to deploy the machine and where to leave it to a person is an expertise worth paying for in its own right — and the most common reason cheap solutions fail in operation.
Always an answer with a source
A RAG agent doesn't answer "off the top of its head". For every answer it shows which price list, drawing, or document it draws on. The company sees where the answer comes from — and that's the key to trust, not decoration.
A deliberate step back where OCR can't manage it
At the engineering shop we decided not to read dimensions from complex drawings — OCR is unreliable there. We read only the title block and bill of materials, where recognition is reliable. The rest is filled in by a person. Knowing what not to entrust to an agent is part of the craft.
A document audit before quoting
Before Enter IT quotes anything, we go through 5–10 real PDFs and verify whether different customers have different title-block layouts. Reliability and price follow from that. No blind promises.
The person at the decision, not the routine
The agent takes over the transcribing and creating, the person keeps the judgment and the approval. That's not a compromise — it's a design that, in regulated fields (energy, manufacturing, sensitive contracts), is what makes deploying AI possible at all.
What an agent measures and how we manage it long-term
An agent gets deployed, but above all it gets evaluated and tuned. Without a baseline and a defined benefit, none gets built here — that's what separates a serious project from a little demo. And we don't hand it over and vanish: operation and long-term management are part of the deal.
What every agent measures
The response time and the time of the whole process, error rate and rework, how much work it actually saves, how adoption grows. Numbers, not feelings — against a measured baseline taken before deployment.
Typical payback of 3–12 months
We build so the return covers further development too. An agent isn't a one-off toy, but a long-term managed layer of the company that improves in operation.
Operation and tuning, not handover and goodbye
We watch where the agent makes mistakes, add rules, expand the scope. A pilot on a single customer with verified logic, then expansion where it pays off.
The data stays with the company
Encrypted transfer and storage, GDPR and Czech legislation, the option of on-prem for sensitive data. The governance and security framework runs from day one, not as a patch at the end.
A TPV agent in ERP Helios — an engineering and design firm
The pain we were solving
Production process planning meant hours of routine every day. An order came in, in the ERP only the top-level project item with uploaded data (PDF + DWG + DXF). The process engineer then, for each part, manually downloaded the PDF, used it to create the component items in Helios, set up the item structure, attached the drawing to each item, and filled in the manufacturing procedure and the time standard. The same very similar items over and over — 15–25 assemblies a week, i.e. 70–120 items, all transcribed and created by a person.
An entry audit instead of promises
Before we quoted anything, we went through 5–10 real drawings and verified whether different customers have different title-block layouts. Reliability and price follow from that. We deliberately built the pilot on one main customer — the same title block means higher reading reliability.
A deliberate decision on what NOT to entrust to the agent
We decided not to read dimensions from complex drawings — OCR is unreliable there. The agent reads only the title block and bill of materials (name, drawing number, steel grade, weight), where recognition is reliable. This boundary is an expertise in itself: it holds the line between a working and a non-working solution.
What the agent does on its own
It loads the PDF of the top-level item, reads the title block and bill of materials, uses the bill of materials to find already-existing similar items in the ERP, and creates the component structure — including carrying over the manufacturing procedure and time standard from the original similar item. It searches for similarity by fields on the master record and metadata from the form.
Human-in-the-loop for what only a person can see
Where the data isn't machine-readable in the drawing (the number of bends, the sheet thickness), a dialog opens with a PDF preview and a numeric field. The process engineer fills in the value from the drawing. The added metadata is collected into a CSV and, via import, the item structure is automatically created in Helios. The agent recommends and creates, the process engineer checks and adds the judgment.
Integration and phasing
The agent stands on ERP Helios (connected via API per the Wiki documentation), reads PDF/DWG/DXF drawings, uses OCR on the title block and bill of materials, and writes into the ERP via CSV import. We split it into two phases: first the manufactured items, in the second phase the purchased and standardized parts — with the option to expand all the way to quoting.
The result
From hours of routine transcribing across 70–120 items a week to an agent that creates the structure and carries over the standards. The process engineer now only checks and fills in what truly requires human judgment. The pilot runs on one main customer with verified logic and room to expand. A competing quote for the same use case was, on top of that, more expensive.
Got a process that eats up your people's time?
Tell us what gets done over and over at your place. We'll design a solution and calculate how much it brings back.