Enterprise
Fulcrum Custom Agent. AI on your process
When your process is not in the catalogue, we design, build and integrate an agent to spec. The same team that builds it trains your people.
What we build
Three forms, one way of working
Fulcrum Custom Agent is not a separate category. It is the same method as the catalogue, applied to a process the catalogue does not cover.
Extension of a catalogue agent
You start from a catalogue agent and take it past the standard scope: one more flow, one more system, your own approval rules.
Agent on a proprietary process
The process is yours and looks like nobody else's. We map it, break it down and build the agent on its real rules, not on a template.
A system of several agents
Several agents coordinated on an end-to-end flow across functions, with explicit handovers and a human control point at every critical step.
All three always include integration with your existing systems, governance (permissions, logs, data in Europe) and training for the people who will use the system.
The frame
Three cases the catalogue does not cover
Process not covered
The work that weighs most is not HR, finance, purchasing, content, go-to-market, legal or training. It belongs only to your business model.
A flow across functions
Order, invoice and payment live in three systems and three offices. Automating one piece moves the bottleneck, it does not remove it.
Specific constraints
Legacy systems, on-premise installations, regulatory or data segregation requirements that call for a dedicated architecture from the first design.
If the assessment shows that a catalogue agent is enough, we tell you and you start there: it costs less and goes live sooner.
The method
The same method, with enterprise constraints
Assessment
We map processes, systems, data and risks in scope. The output is written: what gets automated, what stays with people, what is not worth touching.
Design
System architecture, model choice per use case, integration plan, governance and approval rules. How the result is measured is decided here too.
Build
Iterative development on separate environments, tests with real users, integrations verified against your systems before production is touched.
Adoption
Go-live, training, run and maintenance with written roles: who monitors, who intervenes, who updates when a process or a rule changes.
No duration is stated before the assessment: it depends on how many systems you touch and how accessible your data is.
Governance
Who owns what, written before we start
Data
It stays in your systems and is processed in Europe. We define what the agent reads, what it writes and with which permissions, per role and per environment.
Models
We are vendor-agnostic: the model is chosen per use case among the providers we use, including open options in European cloud or on-premise where constraints require it.
Ownership
Code, configurations and prompts belong to your company under the terms of the contract. Technical documentation is delivered with the system.
Run
Three options: run by Fulcrum, run by your team after training, or a mixed model with shared oversight. The choice is yours and it can change.
Examples
What a system to spec looks like
These are examples of possible architectures, not client cases: we publish no cases and no numbers today.
Typical scenario
From order to payment
Not a client case.
Today
- The order enters the ERP and the invoice is issued by finance
- The payment is checked by hand, when someone remembers
- Three offices, three moments, no single trace of the flow
With the agent
- A procurement agent and a finance agent work on the same flow
- The confirmed order generates the document and the invoice is prepared
- Exceptions reach whoever has to decide, with the reason attached
Non-conformities in production
An agent collects reports, opens and tracks non-conformities and links evidence to plant systems. Integration with MES and machines is assessed case by case.
Document search on internal archives
An agent queries technical, contractual or project archives with permissions per role, always cites the source and logs every request.
Extending Microsoft Copilot
If your environment already runs on Microsoft 365, we add agents that work on company data without replacing the tools people use every day.
Security
Controls that hold up in an audit
Every agent action is recorded with user, time and data touched: the log is meant to be read by auditors, not only by developers. Development, test and production stay on separate environments, with test data that exposes no real information.
Objections
Five questions CIOs ask
"Who maintains it?"
You decide during design: Fulcrum, your team after training, or a mixed model. We hand over code, configurations and documentation, so oversight can change without rebuilding the system.
"Are we locked to one model provider?"
No. The architecture keeps the model separate from the rest of the system, so it can be replaced without rewriting the integrations. The model is chosen per use case.
"Does it work with legacy systems?"
It depends on what the system exposes: APIs, database, files, message queues. We check in the assessment. If it cannot be integrated sustainably, we say so before the quote.
"How long does a project take?"
It depends on the scope agreed in the assessment: number of systems, data quality, environment constraints. We give no durations before seeing your systems.
"What happens to our data?"
It stays in your systems, processed in Europe, with permissions per role and every access logged. Using your data to train models is excluded by contract.
First step
Bring the process, not the technology
A scoping call needs three things: the process that weighs, the systems it touches and the constraints you cannot move.