AI process automation
We automate the work that no longer needs to be manual.
We design business process automation that receives information, applies rules, understands documents or conversations, connects tools and executes actions to reduce repetitive work inside a company.
Not everything needs artificial intelligence. Some tasks are better solved with exact rules; others need to interpret unstructured information; and others should keep going through a person. We design the process around that difference.
- EmailAIWork completed
- DocumentAIHuman review
- MessageAIWork completed
- FormRulesWork completed
- System eventRulesWork completed
What to automate
We don't automate tasks because we can.We automate them when it makes sense.
A good automation candidate repeats, has a known way of deciding, moves a lot of information, crosses tools, depends on deadlines or grows in volume. Select an example process and see how we evaluate it.
Example processes
- FrequencyHow often it happens
- VariationHow much each case changes
- Known rulesWhether there's a clear way to decide
- RiskWhat happens if it runs wrong
- Information loadHow much has to be read, extracted or moved
- Human judgmentHow much discretion each case needs
It happens daily, the data comes from the document and the validation rules exist. The uncertain parts get reviewed; the rest is recorded on its own.
The question isn't “can it be automated?”. It's “which part, with what control, and in exchange for what?”.
Rules, AI and people
Not everything intelligent needs AI.And not everything automatable should run unsupervised.
A serious system splits the work between three roles. Each is good at something different, and most real processes combine them.
Works best when
- The input is structured
- The conditions are known
- The result must be exact and repeatable
Examples
- State changes
- Deadlines
- Routing
- Validation
- Calculations
- Synchronisation
Works best when
- Language has to be understood
- Data has to be extracted from documents
- Something has to be classified, summarised or interpreted
- There's ambiguity the rules don't cover
Examples
- Free text → fields
- Document → data
- Message → intent
- Conversation → summary
- Content → draft
Works best when
- Judgment matters
- Risk is high
- Information is uncertain
- An approval is required
- An exception needs context
Examples
- Approve
- Resolve ambiguity
- Decide exceptions
- Close operations
How they combine in one process
- AI
AI extracts the data from a document
- Rules
Rules validate format, amounts and conditions
- Person
A person reviews only what's uncertain
- System
The system executes the action and records the result
Knowing which role belongs to each step is half the design.
Anatomy of an automation
A real automation has more parts than two connected boxes.
Connecting two tools isn't automating a process. A flow that works on its own needs eight parts, and each answers a question. Select a stage.
Stages
04 · Decision
Rules or AI determine what should happen. Without enough certainty, the decision is flagged for a person.
- 0109:02 · document received
- 02invoice_0412.pdf · 2 pages
- 03known supplier · order 4821
- 04amount > limit → approval
Automation is software engineering, not connecting two boxes.
Where manual work usually hides
Manual work is rarely called that. It's called copying, reading, classifying, remembering.
These are patterns of work, not services. Select one to see how it becomes a flow with rules, AI and a person where they belong.
Today
Someone reads documents or messages to pull out data.
With the system
- 01AIAI extracts the fields
- 02RulesRules check what was extracted
- 03PersonOnly the uncertain parts go to a person
Once the work has a name, a system can be designed to do it.
Documents
A document can become data and actions.
A PDF, an image or an email attachment enters the system. AI extracts the fields, rules validate them, the uncertain parts are confirmed, and the result becomes a record, a workflow or a task.
- Supplier: Aral Supplies Ltd.
- Date: 12/03
- Item: quarterly maintenance
- Net: 1,240.00 · VAT 21% · Total: 1,500.40
- Due: 30 days
- Supplier
- Aral SuppliesCertain
- Date
- 12/03Certain
- Total
- €1,500.40Certain
- Due date
- 11/04Uncertain
- Category
- MaintenanceCertain
- Linked order
- 4821Uncertain
- 01AIExtraction. AI reads the document against a closed schema: only the defined fields, in the expected format.
- 02RulesNormalisation. Dates, amounts and names are converted to one format and compared with what the system already knows.
- 03RulesValidation. Exact rules: the total adds up, the supplier exists, the date is consistent.
- 04PersonConfirmation. Uncertain fields are shown to a person; the rest needs no review.
- 05SystemAction. The record is created, linked to the order, and the approval workflow starts.
- Invoices
- Contracts
- Receipts
- Applications
- Forms
- Reports
Fictional document and values. Which document types are processed, and with which rules, is defined in each project.
In Life Admin, document extraction runs against a closed schema validated on both client and server, normalises dates, amounts and periodicities, flags uncertain fields and asks for confirmation before a payment counts as paid.
The document stops being something someone has to read and becomes something the system understands.
Messages
An unstructured message can become structured work.
An email, a message, a form or a call transcript arrives in natural language. The system understands the intent, extracts the data, identifies the context, qualifies, and creates or updates the workflow with its next action.
Incoming message
Hi, this is Vela Distribution. We need to extend the maintenance contract to the second warehouse before the end of the month. Could you send us a proposal?
Fictional message and data illustrating the pattern.
- IntentAIContract extension
- DataAICustomer: Vela Distribution · Scope: second warehouse · Deadline: end of month
- ContextRulesExisting customer · contract 2041 active · owner: M. Serra
- QualificationRulesExtension opportunity · high priority due to deadline
- WorkflowSystemOpportunity created and linked to the contract
- Next actionPersonTask for M. Serra: proposal by Thursday
In the real-estate CRM we built, a messaging agent asks each client for the missing details and turns the conversation into a structured demand that coordination reviews; and an AI phone assistant answers the call, creates the contact and the demand or prospect, summarises the conversation and hands over to a person when needed. The channels in each project depend on the tools the company uses.
The conversation stays human. What stops being manual is turning it into work.
Assistants
An assistant is useful when it knows the context and has limits.
The difference between a chatbot and a useful assistant isn't the model: it's what it can look up, what it knows about the process and what it's allowed to do.
Generic chatbot
- Knows only the conversation
- Doesn't know the state of anything
- Answers with whatever sounds plausible
- Doesn't know what it can't do
Business assistant
- Retrieves authorised business context
- Understands the system's states
- Answers from real data, and says where it came from
- Can propose actions
- Respects the permissions of whoever asks
- Knows what it must not do
- 01 · ReadRead
Looks up and answers. Changes nothing.
- 02 · SuggestSuggest
Proposes the action; a person confirms it.
- 03 · ActAct
Executes inside a defined perimeter and leaves a trace.
Which level each assistant gets is decided in the design, not by the model.
Life Admin's assistant answers about the user's obligations, payments and deadlines from their own data, and it is read-only: it never writes or modifies a record.
An assistant is worth as much as its context and its limits.
Agents
An agent shouldn't have freedom.It should have a perimeter.
An agent makes sense when software has to interpret a goal, choose between allowed actions, use several tools, inspect the result and continue within limits. Everything else is the perimeter.
- Permissions
- Allowed tools
- Validation
- Limits and budgets
- State
- Audit trail
- Escalation to a person
Goal: prepare the file for request 4821
- Read the CRM
- Search documents
- Create a draft
- Query an API
- Delete data
- Send a payment
- Change permissions
Example perimeter. What an agent may do in each project is defined, limited and recorded.
What surrounds the agent
- 01Permissions
- 02Allowed tools
- 03Validation
- 04Limits and budgets
- 05State
- 06Audit trail
- 07Escalation to a person
The messaging agent in the CRM we built runs within limits: a daily sending cap, strict respect for opt-outs, checks before every message, and a task for coordination every time it creates or completes a demand.
Useful autonomy is the kind that fits inside a perimeter someone designed.
Workflow automation
Most automation doesn't need AI. It needs executable process logic.
When something happens, the system checks a condition, acts, and leaves the process in a new state. These patterns exist in systems we have already built.
- EventNew recordConditionHas the minimum dataActionAssign an owner and create the first taskStateAssignedReal-estate CRM
- EventDeadline approachingConditionFewer than N days leftActionCreate an alert; if it passes, escalateStateFollowing upReal-estate CRM
- EventState changedConditionState = approvedActionCreate the next tasks and notifyStateIn progressReal-estate CRM
- EventPayment confirmedConditionVerified at sourceActionUpdate the process and notify by webhookStateCompletedFivo
- EventForm submittedConditionValid fieldsActionCreate the structured recordStateNewPattern
- EventExternal system changedConditionThe data exists hereActionSynchroniseStateSynchronisedReal-estate CRM
- EventMatch foundConditionMatching criteria metActionSurface the opportunity to the ownerStateOpportunityReal-estate CRM
Thresholds (days, amounts, workloads) are company parameters. They're configured, not programmed.
Automation isn't magic. It's process logic that executes.
Follow-up
A process shouldn't move forward only when someone remembers.
The system can reason exactly about dates, states, inactivity, missing information, owners and the next required action, and surface the follow-up at the right moment.
What it reasons about
- Date and deadline
- Process state
- Days without activity
- Missing information
- Owner
- Next required action
- First-contact control in working hours: a warning at four hours and a return to the coordination queue at eight
- Demands with no activity for more than seven days, going cold at thirty
- Acquisitions stalled for more than fifteen days
- Mandates expiring in thirty days
- Deferred documents with alerts at ten and fifteen days
- Request 4821No first contact within the deadlinedue in 2 h
- Contract 2041Signed annex missing10 days pending
- Vela opportunityNo activity7 days
- File 0412Approved, no next tasktoday
- Aral renewalExpires in 30 daysschedule
The value isn't “more sales”. It's that nothing gets forgotten.
Automation across tools
Many manual tasks exist because the tools are separate.
Automating usually means orchestrating the systems that already exist, not replacing them. The automation layer moves information between them and keeps the state of the process. Select a flow.
- 01 · FormSubmitted
- 02 · CRMRecord created and assigned
- 03 · CalendarAppointment proposed
- 04 · EmailConfirmation sent
- CRM
- Calendar
- ERP
- Documents
- Payments
- Messaging
- Database
- External API
Example flows. Which tools take part, and what each allows, is studied in the project.
When the tools talk to each other, nobody has to be the messenger.
Human control
Automating doesn't mean removing control.
Every automatic decision can end in one of three ways. Which one depends on certainty, on risk, and on what the company has decided must never run on its own.
Example cases
- Certain
Execute
Rules or confidence allow acting without intervention.
- Uncertain
Ask for review
The information isn't certain or the risk is higher: a person confirms.
- Exception
Escalate
The system can't decide safely: it hands over with the full context.
The labels are illustrative: certainty thresholds and the actions that always require a person are defined with the company.
Control isn't a brake on automation. It's what makes it possible to trust it.
Exceptions
The automatic process also needs to know what to do when something fails.
Demos show the happy path. A system in production meets missing data, duplicate events, services that are down and unexpected formats. Designing what happens then is part of the work.
What can fail
- Missing data
- Duplicate event
- External service failure
- Unexpected format
- Timeout
- Permission error
- Ambiguous interpretation
- Partial execution
What the system does
Retry
Temporary failures of an external service, with growing waits and a maximum number of attempts.
Pause
When information is missing, the process stops in a clear state instead of continuing with incomplete data.
Surface the error
Nothing fails silently: the exception appears where someone will see it.
Request the information
If a piece of data is missing, it's requested from whoever can provide it, and the flow continues on receipt.
Undo where possible
If an action completed halfway, it's reverted or left marked as partial.
Continue safely
What doesn't depend on the failure moves on; what does, waits.
Trace of an exception
- 10:41
ERP synchronisation: no response
- 10:41
Retry 1 in 30 s · retry 2 in 2 min
- 10:44
Still no response: process paused, owner notified
- 11:10
ERP available: synchronisation completed, no duplicates
What separates production automation from a demo is what it does when something goes wrong.
Reliability
If an automation works on its own, it has to leave a trail.
You need to know what happened, why it happened and what remains unresolved. That is designed: state, history, validation, permissions, monitoring and visible failures.
What you need to know
- 01What happened
- 02Why it happened
- 03What remains unresolved
What's underneath
- State
- History
- Audit trail
- Duplicate-safe execution
- Retries
- Validation
- Permissions
- Monitoring
- Human review
- Visible failures
- 09:02InputDocument received from a known supplier
- 09:02Extraction6 fields · 2 uncertain
- 09:03ValidationTotal matches the lines
- 09:03DecisionAmount above the limit → approval
- 09:31ReviewM. Serra confirms the due date
- 09:32ActionRecord created · ERP updated
- 09:32StatePending approval · no errors
No “zero errors” and no showcase certifications: a trail, control and failures you can see.
Data and permissions
Automation should only access what it needs and do what it's allowed to.
Every flow and every assistant works with a defined access: the data essential to the task and the explicitly permitted actions. Everything else is out by design.
- 01
Least access
Each automation reads only the data its task requires.
- 02
User and role permissions
An assistant answers with what the person asking is allowed to see.
- 03
Tool boundaries
Available actions are declared one by one; what isn't declared doesn't exist.
- 04
Sensitive data
It's identified and treated differently: what is sent, where, and what never leaves.
- 05
Explicit action scopes
Reading, suggesting and acting are different levels, decided by design.
Which data an external AI provider processes, and which never leaves the system, depends on each project's architecture. We define it and put it in writing; we don't promise regulatory compliance that hasn't been verified.
Models are components, not the product
The model changes.The system stays.
A production AI system separates the process, the data, the permissions, the workflow and the validation from the specific model provider. That way the company isn't designed around “we use model X”.
What is yours and stays
- 01Business process
- 02Data
- 03Permissions
- 04Workflow
- 05Validation
Interchangeable component
- OpenAI
- Claude
- Other providers depending on the project
Chosen per task by cost, quality and data requirements, and replaceable without rebuilding the system.
The value is in the system around the model, not in the model.
Where AI is unnecessary
There are also processes where AI is unnecessary.
When the input is structured and the result has to be exact, the right answer is deterministic software. AI adds value where there's language, documents or ambiguity. A map of where each task belongs:
- Exact calculation
- Validation rule
- Simple routing
- State change
- Database lookup
- Permission check
- Understanding language
- Reading documents
- Resolving ambiguity
- Classifying text
- Summarising
- Drafting
Choosing well is cheaper, more reliable and easier to maintain than using AI for everything.
Real proof
Three kinds of work. Three real systems. No AI forced in.
Understand, decide and execute. These three systems exist and are in use; each automates a different kind of work, with AI only where it was needed.
- 01 · UnderstandUnstructured information turned into data
- 02 · DecideRules and criteria applied the same way every time
- 03 · ExecuteSystem actions, verified and traced
Real-estate operations
Custom real-estate CRM
- Understand
- Decide
- Execute
- Automatic matching between demand and supply, with alerts for the best matches
- A messaging agent that completes demands and an AI phone assistant that creates contacts and summarises calls, with coordination review
- First-contact control, inactivity, stalled acquisitions and expiring mandates
- Synchronisation with portals, calendar and signature; documents that unlock the process
- 40K+properties managed
- 20+custom modules
- 45scheduled automatic processes
Personal administration
Life Admin
- Understand
- Decide
- Execute
- Extraction of obligations from documents under a closed schema, with uncertain fields and confirmation
- Cycles and renewals derived from frozen terms; a payment only counts with evidence
- Classification of purchases and warranties from receipts and orders
- A read-only assistant over the user's data
- 22entities
- 12server functions
- 939tests
Payments
Fivo
- Understand
- Decide
- Execute
- Payment received → on-chain verification → payment state, from pending to completed or failed
- Cross-network movement with receipt verification
- Periodic processes for withdrawals, refunds and payment recovery
- Signed webhooks with retries and delivery logs
- 9mainnet networks
- 5webhook events
- 0AI where it isn't needed
Real proofFeatures and figures verified in each system's repository. Client names and specific vendors stay confidential.
We don't force AI into every automation. We choose the tool each kind of work demands.
Explore
What consumes time today?
Select what resembles your situation. For each one we show the system pattern that usually solves it. They are possible patterns, not promised solutions.
Possible system pattern
- 01AIExtraction under a schema
- 02RulesValidation and normalisation
- 03PersonConfirmation of what's uncertain
If you recognised yourself in one of these, we already know where to start.
Discovery
Before automating a task, we take the process apart.
“I want to automate request handling” contains several decisions. These are the questions we use to break a task into system components. Select one.
I want to automate request handling
Select a question
- TriggerWeb form, email or phone call
- InputRequester details, reason and attachments
- Sources—
- Inspection—
- RulesType, amount and priority decide the team
- Exception—
- Action—
- Notifications—
- Edge cases—
- Control—
- Verification—
We automate the process, not the sentence.
From a small automation to a system
“Automating” can mean one task or a whole operation.
These aren't packages: they're scopes. They help you understand how big the problem is and what kind of system solves it.
02
Workflow
Several chained actions and decisions with states.
Receive, validate, approve and record
The right scope is the one that removes work without adding complexity.
Impact
What changes when the work stops being manual.
We don't promise percentages. What can be designed, measured and checked in each project is this:
- Less repetitive work
- Fewer manual handoffs
- Faster processing
- More consistent execution
- Better traceability
- Less dependence on memory
- More operational capacity with the same team
- Information structured at the source
- Better visibility of what is happening
Where the opportunity is
- Repetition
- Volume
- Manual steps
- Dependencies
Indicative. The real analysis is done on the actual process.
What we deliver
From the manual process to the system in production.
You don't need to assemble a consultant, an integrator and an AI vendor. The project can cover the whole path:
01
Manual process
- Process analysis
- Automation design
- Rules / AI / person decision
02
Designed automation
- Workflow engineering
- AI integration and document processing
- Assistants and agents with bounded tools
- Backend automation, scheduled processes and events
- Integrations, APIs and webhooks
03
System in production
- Human-review flows
- Monitoring and audit
- Custom interfaces where needed
- Maintenance and evolution
One party responsible for the process, the system and what happens when something fails.
How we work
An automation project, step by step.
01
Observe
Understand how the work happens today.
02
Decompose
Inputs, decisions, tools, rules and exceptions.
03
Decide
What goes to rules, what to AI and what stays with a person.
04
Connect
Data and systems.
05
Automate
Build the workflow.
06
Control
Validation, permissions, exceptions and visibility.
07
Evolve
Improve from real operation.
When it makes sense
When this service makes sense, and when it doesn't.
It fits when
- Repetitive work consumes time that matters
- Information has to be read, classified or entered again and again
- Processes depend on follow-up
- Several tools require manual coordination
- The same rules are applied repeatedly
- The process is stable enough to automate parts of it
- AI could help interpret unstructured information
- Existing automations have become fragile or opaque
It's better to wait when
- The process changes every week
- Nobody can explain how it works today
- Every decision requires different human judgment
- Automating would add more complexity than it removes
- The volume doesn't justify the engineering
If it fits, we start with the process. If it doesn't fit yet, we'll tell you.
Your process
Tell us which work repeats.
You don't need to know whether it takes AI, conventional automation or custom software. Tell us what a person does today, which information they use and what should happen. We determine which part makes sense to automate and how to do it with control.