Solutions · Enterprise
Custom Enterprise Automation
For work that fits no template: your steps, your systems, your guardrails, with a named agent on each.
Why custom work is hard
The process that fits no template, as people describe it
Nobody asks for a custom agent. They say no product does what we do, that the scripts somebody wrote are now a liability, and that the rule everything depends on is in a PDF.
What you hear
No product does what we do
Three vendors have demonstrated a workflow that looks like yours and is not. The step that makes your process yours is the one none of them has, and it is the one that takes the time.
What you hear
We built it ourselves, and now it is a problem
A set of scripts written by someone who has since left, holding together a process that matters. Nobody dares change it and nobody can explain what it decides.
What you hear
The contracted rate is in a PDF
The rule the process depends on, a tariff, a tolerance, a service level, is in a document, not a system. Checking it means a person opening the contract every time.
What is underneath
Templates assume a shape
Off-the-shelf automation works for the process it was designed around. Yours has an extra lookup, a different approval path and a document type nobody else handles.
What is underneath
The rules exist, but informally
Everyone knows the tolerance and nobody has written it down. Making it explicit is most of the project, and it is the part a product cannot do for you.
What is underneath
Build and run are treated as one thing
A bespoke system means bespoke maintenance. The alternative is a configured set of agents on a platform that is maintained whether or not your process changes.
How PTAS AI builds it
Configure what exists, build only the step that is yours
A custom workflow is mostly library agents configured to your rules, plus one or two built for the step no library covers. The guardrails, the decision record and the measurement come with the platform, so what is bespoke stays small.
-
01
Understand
We map the process as it genuinely runs, with you, including the step that makes it yours. For each step: what triggers it, what it reads, what it decides, where the result goes, who may override it. Then we define good and bad in numbers, so the finished workflow can be judged against something rather than against a feeling.
The map is the specification, and it is yours
-
02
Decide
Each step is assigned to an agent. Most come from the existing library: reading a document, looking up a rate, comparing two values within a tolerance, routing to an approver, posting a result. The step that is unique to you is built as its own agent with a narrow job. Your informal rules become configuration with thresholds, and the gate where a person must decide is agreed before anything runs.
Assembled from parts, with one part built for you
-
03
Act
The chain runs on the Agentic AI Platform against a month of your real cases before it runs live. Each agent reads from and writes to the systems on either side of its step, through their APIs or files. Routine cases run end to end. Cases that cross a tolerance or a threshold stop at the named person with the evidence and the question.
Proved on your cases, not on a demo
-
04
Verify
Every decision is kept in full: what the agent saw, which rule it applied, what it did and what it checked afterwards. When a rate changes or a system is upgraded, the agent that depends on it is the one that changes, and the rest of the chain does not. Extending to a second process starts from a measured first one.
Explainable months later, without anyone reconstructing it
Worked example
Three systems, four agents, one gate
A freight cost audit has the right shape: high volume, a contracted rate in a document to check against, and a tolerance above which somebody should look. Four of the agents came from the library. The rate lookup against the carrier contract is the one built for it.
Worked example — freight cost audit · Illustrative example
Three systems, four agents and one human gate above a value you set. None of that is a product feature — it is a workflow assembled from parts that already exist.
Assembled from parts
Four agents from the library and one built for the step that is yours.
Bounded up front
The tolerance above which a person decides is agreed before anything runs.
Crosses systems
The integration layer stops being a person with three windows open.
Key capabilities
Eight things a custom build has to do well
Writing the unique step is the visible part. Scoping honestly, keeping the custom part small and measuring from day one are what decide whether it is still running in two years.
Scoping
Process mapping
The process documented as it runs, step by step, with triggers, inputs, decisions, outputs and overrides. Delivered as a document you keep whatever happens next.
Scoping
Candidate assessment
An honest view of whether the process should be automated: volume, variety, whether rules exist, whether the decision needs context not in any document. We say no when the answer is no.
Agents
Library agents, configured
Document reading, lookups, comparisons, routing, approvals and posting from the existing agent library, configured to your rules and your systems rather than built again.
Agents
Custom agents for your step
The step no library agent covers, built as a narrow agent with a defined input, a defined output and tests, so it can be measured and replaced without touching the rest.
Rules
Rules from documents
Rates, tariffs, service levels and tolerances that live in contracts and PDFs, read by DocPro into structured rules the agents can apply, and kept current as the documents change.
Rules
Gates and overrides
Where a person decides, defined as a step with a named role, a reason requirement, delegation and escalation. Overrides are recorded and reported, so a pattern of them is visible.
Run
Integration on both sides
Each step reads from and writes to the systems it touches, through API, file exchange, events or a custom connector where nothing else exists, with the method confirmed per system.
Run
Measurement built in
Volume, cycle time and exception rate per step from the first day, against the good and bad you defined, so the decision to extend is a number.
Decisions and exceptions
What a decision looks like afterwards
The test of a custom workflow is not whether it ran, but whether anyone can say why it did what it did six months later. Every decision is kept with what the agent saw, the rule it applied and what it checked afterwards.
One decision, kept in full · Illustrative example
This is what separates an agent from an automation: it can tell you why, months later, without anyone reconstructing it.
A person enters the chain only at the gate you placed: a variance above the tolerance, a rate the contract does not cover, a lookup that found nothing. They see the case, the evidence and the one question, and their decision joins the same record. When a rate changes, the rule changes with an effective date and the record shows which rate applied to which case. Nobody reconstructs anything.
Business outcomes
What changes, and how you would measure it
We do not quote returns before mapping the process. We do define good and bad in numbers at the start, on your cases, so the decision to extend is based on something.
What changes
A process that is written down
The map and the rules exist as documents and configuration rather than as the knowledge of two people. Measure it by asking a new joiner to explain the process from the record.
What changes
Hands per case
Count the people who touch an ordinary case from trigger to completion, before and after. For a routine case the target is none, and the measure shows how far from it you are.
What changes
Cycle time, by step
Time from trigger to completion, broken down per step, so a slow process reveals which step is slow and whether it is a person, a system or a rule.
What changes
Exceptions with a reason
The share of cases that stop at a person, by reason. A reason that fires constantly is a rule to revisit or a data problem upstream, and either is useful to know.
What changes
Decisions that can be explained
Any case, picked at random, explained from the record: what the agent saw, which rule it applied, what it did and who decided. This is what separates an agent from a script.
What changes
Change without a rebuild
The time and risk involved in changing a rate, a tolerance or an approver. It should be a configuration change with an effective date, not a development ticket.
Integrations
Each step connects to the systems on either side of it
A custom workflow usually exists because the systems do not talk. Each agent reads from and writes to the system its step touches, through API, file exchange, events or a connector built for it, and the systems stay the systems of record for what they hold.
REST API
Any system · read and write
Webhooks
Events in and out
SAP
ERP · API, IDoc or file
Oracle
ERP · API or file
Microsoft Dynamics
ERP and CRM · API
NetSuite
ERP · API
Tally
Accounting · XML import
Zoho
CRM and accounting · API
QuickBooks
Accounting · API
Four integration methods are possible: native integration, API integration, file or flat-file exchange, and custom integration. The systems named here are planning examples; a custom workflow often involves a system not on this list, and the method for each is confirmed during assessment rather than assumed. See integrations for the full list.
Security and governance
Controls an auditor would recognise
Custom does not mean unbounded. These are the controls every workflow on the platform runs under, custom agents included, and the security page has the detail.
Agents bounded by configuration
Each agent has a narrow job, named systems it may read and write, and limits on what it may decide alone. The boundary is agreed before the first run and recorded with every decision it shapes.
Human gates enforced
A step that requires a person cannot be passed by an agent, and a person cannot pass it without a recorded reason. Delegation and escalation are part of the step, not a workaround.
A complete decision record
Every case carries what each agent saw, which rule it applied, what it did and what it verified, with the documents attached. Queryable for status and exportable for audit.
Deployment and data handling
Cloud, private cloud or on-premise deployment where supported, role-based access to cases and configuration, data retained under your policy, and ISO/IEC 27001-aligned practices. Custom agents are tested and versioned like the library ones.
Product connection
The products that deliver it
A custom workflow runs on the Agentic AI Platform and is assembled from the agent library, with DocPro reading whatever documents feed it. The custom agent is the smallest part, by design.
FAQ
Questions operations and IT leaders ask
How is this different from hiring a development team?
Most of the chain is agents that already exist, configured rather than built: reading documents, applying rules, routing, posting. What is built is the one step that is specific to you, as a narrow agent with tests. What you are buying is the runtime, the guardrails and the decision record around all of it, rather than a bespoke system that somebody then has to maintain. Where genuinely new engineering is needed, it is scoped separately and said out loud.
How is this different from business process automation?
Business process automation is the general case: a repeatable process assembled from library agents and your rules. Custom enterprise automation is for the process where one or more steps fit no existing agent, where the rules live in a contract rather than a system, or where the integration is to something unusual. The approach is the same; the difference is how much has to be built rather than configured, and we tell you which before you commit.
How do we know our process is a good candidate?
High volume, low variety, rules that exist even if nobody has written them down, and a person currently acting as the integration layer. If the decision genuinely needs context that is not in any document, keep it with people. We would rather say that in the first conversation than build an automation that escalates everything.
Who maintains it once it is running?
You do, in the sense that changing a threshold, a rate or an approver is configuration with an effective date rather than a support ticket. The platform and the library agents are maintained by us. Where a system your process integrates with changes, that is a scheduled conversation, and the agent that touches that system is the only one that changes.
How long does it take, and what does it cost?
The typical range is six to fourteen weeks for one process, and it varies with how many steps need a custom agent, how many systems are involved and how long the rules take to agree. Cost follows the same drivers, and we scope the custom part separately from the configured part so you can see which is which. We will not quote a figure before the mapping, because the mapping is what makes the figure honest.
Keep reading
Related solutions and products
Enterprise Workflow Automation
The cross-department, cross-system case, with a worked example.
Read more →Business Process Automation
The general case, assembled from library agents.
Read more →Build with PTAS AI
Product engineering, agent development and modernisation as services.
Read more →Agentic AI Platform
The runtime a custom workflow is built on.
Read more →Next step
Bring the process no product fits
Describe the step that makes it yours. We will tell you honestly how much of the rest already exists, and whether the step is worth building.