Contract and document review
Checks a contract or commercial proposal against the company policy and returns it as a Word file with tracked changes. Each edit shows the original text, the proposed replacement and the regulation clause behind it.
Primo Epic
Enterprise AI agents
you can control and audit
Primo Epic is an AI agent platform that runs on your own infrastructure. Agents review contracts, check invoices against policy and process spreadsheets. Every change waits for an employee’s approval, every decision is recorded with its reasoning, and access follows your roles and security rules.
RPA + AI agents
A robot repeats steps that are written down.
When an exception is not in the robot’s script, the task goes to an employee, who looks up the regulation, the related documents and the history of the operation. The reasoning behind the decision is rarely recorded anywhere.
An agent decides within rules you set, and records why.
It collects the documents and data, compares them with company rules, and either prepares the result for approval or hands the decision to an employee, with the regulation clause it relied on and every step kept on record.
Employees handle exceptions and decisions, not searching and manual cross-checking.
Capabilities
Agents for work that needs judgment, not just repetition
Invoice and document verification
Reconciles primary documents with the contract and accounting policy, lists each discrepancy with a reference, and recommends whether to accept. Straightforward cases are prepared automatically; disputed ones go to an accountant.
Spreadsheet analysis
Reads, corrects and calculates over Excel workbooks. Employees ask questions in plain language and receive ready selections or calculations, computed by code in an isolated environment.
Answers from policies and knowledge bases
Answers employee questions from company policies with a reference to the clause. If the documents do not contain the answer, the agent says so.
Primo RPA robots as tools
For systems without an API, the agent calls Primo RPA robots through Orchestrator. The robot stays; the agent handles the exception and decides when to call it.
Connection to company systems
ERP, accounting and other systems with an API are connected through MCP servers. Scanned documents are recognized by Primo AI Server, then reviewed by the agent.
What makes an AI agent acceptable in an enterprise is not what it can do but how far it can be controlled. Primo Epic puts that control in the platform, not in the prompt.
Control
Two layers of control, one of them independent of the model
Policy — your rules
- —Company rules for the case, written from your regulation: wording for the model, severity and a citation of the clause
- —Maintained by a lawyer or methodologist, versioned, and published without a programmer
- —The model reads the rules and follows them. As with any language model, it can miss one
System checks — enforced by platform code
- —Run limits: steps, tokens and time per task
- —Allowed tools: anything outside the list is blocked or sent for confirmation
- —Input and output filter: stop words and instructions injected through document text
- —Personal-data masking in model responses
- —Reaction is set per check: block, send for confirmation or mask. Values are set for the platform and refined per agent or step
Changes to documents and data wait for an employee’s decision on each edit. Confirmation rules are fixed when the agent is published, and at run time they can only be tightened. By default, no action that changes data runs without it.
A decision that cannot be explained cannot be audited. For every task, the platform keeps a record of what the model decided, which tool it used and who approved the result.
Traceability
Every decision can be reconstructed afterwards
Every model step
Each step of the agent with its duration and the tokens the model used, so a run can be replayed in order.
Every tool call
Which tool the model called, with what arguments, and what came back.
Every decision on an edit
The clause, the rule code and severity, the original and proposed text, the model’s reasoning and who accepted or rejected it.
Every system check that fired
Limits reached, blocked tools and filtered content appear in the same record as the step that triggered them.
Every hand-off
When the assistant passes a request to a specific agent, the record shows to whom and why.
A separate audit log
Permission grants and revocations, role changes, blocked accounts and denied access attempts. Logs can be exported to external systems, including SIEM.
Control and records only matter if the platform fits into the corporate security model. Access, execution and tool connections follow the rules your security team already applies.
Security
Built to pass your security review
Inside your perimeter
The platform, data, files and logs are stored on your servers and no telemetry leaves. Outbound connections go only to the model, connected systems and tools you approve.
See deployment architecture →Your sign-in and groups
Users sign in through your OIDC provider or the bundled Keycloak, with groups from LDAP or Active Directory. The platform stores no passwords of its own.
Roles and object permissions
Four roles define sections and actions. Permissions at four levels control access to each agent, model, server and policy. Rights are checked on the server for every action, and refusals are logged.
Agents act with the user’s rights
An agent acts on behalf of the employee who set the task and cannot do what that employee is not allowed to do. Each employee sees only their own conversations.
Tools reviewed by security
A tool server is marked as trusted by an administrator only after your security review. Until then, any action that is not read-only needs confirmation.
Isolated code execution
Code the agent writes for calculations runs in a disposable container with no network access. Access tokens for models and tools are stored encrypted.
Cloud chatbots and agents solve different problems. The difference shows up in where the work runs and who stays in control of the result.
How an agent differs from a chatbot
Chatbot on a cloud model
- —Runs in the model vendor’s cloud; the vendor decides which models and connectors are available
- —Answers mostly in text; actions in systems go through the vendor’s connectors
- —Control and logs sit on the vendor’s side
Primo Epic agent
- —Runs on your servers; you choose the model
- —Corrects the document, prepares the record in the system and calls Primo RPA robots, with confirmation before data changes
- —Confirmation cards, platform-level checks and a step record kept inside your perimeter
Not every process is a fit. Here is an honest read on where Primo Epic performs best, and where it may not be the right call yet.
When Primo Epic is the right choice
Good fit
- —Contracts, invoices, applications or reports that must be checked against a written regulation
- —Decisions that need a reasoned, auditable trail an internal auditor can follow
- —Exceptions that robots currently pass to employees
- —Data that has to stay inside the company perimeter
- —Scanned documents, with Primo AI Server providing recognition
Watch out for
- —No written regulation or rule set to base decisions on
- —No success criteria agreed before the pilot
- —No route to a language model: an accelerator server, a corporate gateway or an approved cloud model
- —Processes that must run fully unattended; today a task is started by an employee or by a calling system
- —Environments that require a specific security certification of the platform; requirements are reviewed before the pilot
Rollout and controlA measured rollout,
A measured rollout,
with controls built in.
2–3weeks
Process assessment
Typically before a pilot: task volumes, exceptions, regulations, systems and security requirements.
6–10weeks
Pilot with agreed success criteria
A working agent in your perimeter, measured on a control sample of your own documents.
4
Platform-level system checks
Run limits, allowed tools, input and output filter, personal-data masking. They apply regardless of the model.
1
Catalog entry to change the model
Agents are not rebuilt. Quality is re-checked before switching.
Timelines are typical for an initial deployment and depend on infrastructure readiness and the scope of policies. The figures describe the delivery approach and platform design, not customer results.