How agentic process specification works in practice
Our method rests on one principle: a process can be automated only once it has been described precisely enough. That is why the work always starts with specification, not with a technology choice. In a specification workshop, the people who run the process describe their own work; our platform turns the description into a machine-readable specification; and human approval points and reviews are built into the spec before a single line of implementation exists. You choose the implementer: your own team, a partner of your choice, or us. Finally, we verify that the implementation in production matches the specification.
The specification workshop makes hands-on expertise visible
The people who know a process best are the ones who run it daily. In the workshop they describe their workflow step by step, and our platform structures the description into a model as they go: a process decomposes into workflows, workflows into agents, and agents into technical tasks. Participation requires no technical skills. Being able to explain how the work is done is enough.
The machine-readable specification is technology-independent
The workshop produces a specification that states unambiguously what each agent must do, where its data comes from, where it goes, and under what conditions a step counts as done. The specification binds you to no platform or vendor, and it is the client's property. Process diagrams, work instructions and the implementation baseline are generated from the same source, so documentation cannot drift away from what the system actually does.
The human is in the structure, not in an appendix
Approval points are designed into every process before implementation: where a human reviews, approves or decides. A significant share of the steps in an agentic process are deterministic tools and human tasks, not language-model calls. This is a deliberate design choice: it keeps the process predictable, the costs controlled and the responsibility with people.
Reviews and an auditable trail
The specification advances to production through review gates that check coverage, risk classification and the sufficiency of approval points. A running process produces a trail showing what was done, who approved it and which version of the specification the implementation is based on. Compliance documentation (including foundations for EU AI Act assessments and ISO 42001 work) is a by-product of specification, not a separate project.
Implementation: the management model defines who builds and owns what
Implementation divides into the layers of the management model, from the specification platform to the cloud architecture. Typically we supply all layers at the start and hand them over as the client matures. The target state is that the client's own small team builds the processes, with Managentics providing the platform and technical consulting.
01 // Management model
Management model: who builds, who owns, what you pay for
The management model divides the delivery of agentic AI into four layers and makes visible what usually stays vague in AI programmes: who builds what, who owns which layer and what you are actually paying for. The layers are the specification platform, process building, the runtime environment, and the cloud, security and compliance architecture. At the start we typically supply all layers. As maturity grows, building and the runtime shift to the client, and our role narrows to the platform and technical consulting.
The layers in brief
The specification platform is the tool for describing and governing processes; it is our product and stays with us. Process building turns specifications into working processes; it shifts step by step to the client's own team. The runtime environment is in the client's own cloud, on the client's own accounts, from day one. The architecture layer secures the foundations of security, access control and compliance, and it is designed together with the client's IT.
Why the division is worth making visible
Once the layers are separated, costs can be compared and decisions made layer by layer: what is bought as a service, what is built in-house and what is tendered. Without the division, programmes are bought as a lump, comparison becomes impossible and vendor dependency forms unnoticed.
Q:Where is our data?
In your runtime environment, on your cloud accounts. The specification platform handles process descriptions, not production data.
Q:How big does our own team need to be?
In the target state a few developers are enough to build and maintain an entire process portfolio, because the specifications and the platform make the work repeatable.
Q:Can the layers be bought from different vendors?
Yes, and the division is designed for it. The specification ties the layers together regardless of who supplies each one.
Frequently asked questions
Q:Do we need to have chosen an AI platform before starting?
No. The specification is technology-independent, and the platform decision is best made once you know what you are building.
Q:Our processes are not documented. Is that a problem?
No, it is the starting point. The specification workshop exists precisely to capture undocumented work.
Q:Does this replace our current IT partner?
No. We specify and verify; the implementer can be your current partner, your own team or us. A clear division of roles usually improves the partner's output.
Q:How long does specifying one process take?
A single workflow typically goes from workshop to a production-ready specification in weeks, not months. The exact duration depends on the scope, and we estimate it in the discovery call.