A sales order becomes an Armaor order
The agent reads a confirmed sales order in the ERP, creates the order in Armaor and loads its BBS lines from the engineer's schedule. The Armaor writes wait for the production manager.
On-prem applications
Use Armaor from Claude, ChatGPT or your own agents over MCP or an API. Choose each action per agent, require approval for writes, and see who did what.
Updated Oct 28, 2026
Armaor runs the production of rebar factories on a server inside the plant, and until now no AI agent could use it. Contro1 serves the Armaor Web API as tools on the Contro1 MCP server: an agent in Claude, ChatGPT, Copilot or your own code calls Armaor actions, each allowed per agent, the important ones approved by a person, and every call recorded. A small connector on the Armaor server makes it work without opening a port or a VPN. The same agent can work in Priority or any other system you connect, so orders, plans, stock and delivery notes move between them.
Armaor, the rebar production software from Ariadis, runs on a server inside the plant: orders, BBS lines, production planning, cutting tags, stock, deliveries. Its Web API answers only on the plant network, and it has no MCP server of its own.
So an AI agent cannot ask Armaor "which orders are late" or "put this order in production". Someone still opens Armaor, looks it up and types it in, and then types the same thing again in the ERP.
Contro1 serves Armaor's operations as tools on the Contro1 MCP server. Claude, ChatGPT, Microsoft Copilot, Cursor or an agent you build calls them like any other tool. A connector installed on the Armaor server runs each call inside your network.
Before anything runs, Contro1 checks which agent is calling, for whom, and whether that agent may use that action. Where you said so, a person approves first. Every call is recorded.
Watch it in the agent capsule: Armaor added to an agent that already works in Priority, each action chosen, approval set, approved, and on the record.
Armaor stays where it is, on your own server, on-prem or self-hosted in your cloud. You install a small connector on that server, or on another always-on server that reaches it. The connector opens a secure outgoing connection to Contro1 and waits for work.
When an agent calls an Armaor action, Contro1 checks the grant and the policy, waits for approval if needed, and hands the signed job to the connector. The connector calls Armaor at its local address, for example http://127.0.0.1:3001, and returns the answer.
| With the Contro1 connector | |
|---|---|
| Firewall | Outbound HTTPS to api.contro1.com on port 443. Nothing inbound. |
| Armaor on the internet | Never. It answers only on the server or the plant network, as today. |
| Armaor key | If your Armaor needs one, it is typed into the setup file on the server and never leaves it. |
| What the connector can call | Only the reviewed Armaor operations in its setup file. A job carries inputs, never a URL, a header or code. |
| Server | Windows Server 2016 or later (the first install ran on Windows Server 2025), Linux with systemd, or macOS. It runs as a service and restarts on its own. |
| Setup time | About 15 minutes with your IT person, including the checks. |
Installing the connector, on a Windows server:
Connect AI agents to internal and on-prem applications, with install steps for IT
These are the Armaor Web API operations Contro1 reviewed at its first Armaor install: 68 operations, 32 that read, 30 that write and 6 that delete. Each one has its effect and risk set, and none runs for an agent until someone allows it in Access. Your Armaor version may expose more or fewer; we check yours before you publish.
| Area | Lists out (read) | Lists in and changes (write) |
|---|---|---|
| Orders | List orders by dates, factory, code and status; get one order | Create and update orders; authorize or remove ERP authorization; delete an order |
| BBS | Get the BBS lines of an order | Replace all BBS lines of an order (members and shapes; Armaor numbers the rows) |
| Production and planning | Planning and production progress of orders | Change an order's production date; put an order in production and create its tags; send an order to the PROGRESS mesh machine |
| Tags and traceability | Cutting tags, member tags, tag to BBS row links, traceability | Change a tag's scheduled date; record traceability; print a cutting tag on a machine |
| Stock | Stock by factory, stock tags, stock orders | Create a stock entry, assign a stock tag to a machine, create or update a stock order |
| Clients and sites | Clients, sites, and those created or changed since the last call | Create, update or delete clients and sites |
| Suppliers and purchasing | Suppliers and local purchase orders | Create, update or delete suppliers and local purchase orders |
| Products | Products and member sub-types | Create and update products and member sub-types |
| Deliveries | Delivery notes | Set the invoice number on a delivery note |
| The factory | Factories, machines, workers, vehicles | None: read only |
A sensible start for most plants:
| Armaor action | For a planning or customer service agent |
|---|---|
| List orders, get planning and progress, list cutting tags | Runs on its own. Reading is routine. |
| Change production date of an order | Waits for the production manager. |
| Put an order in production, replace BBS lines | Waits for two people, for example the plant manager and the production manager. |
| Delete an order, client, site or supplier | Not granted. The agent never sees it. |
Most Armaor plants also run an ERP. In Israel that is often Priority; elsewhere SAP Business One, Microsoft Dynamics or something else. Today the two meet through a person retyping, or a sync nobody wants to touch.
An agent can work in both, with the same controls. In the clip, Production Planner already has three Priority actions; Armaor is added beside them. Each system keeps its own grants and approvers, and both appear in one record.
The agent reads a confirmed sales order in the ERP, creates the order in Armaor and loads its BBS lines from the engineer's schedule. The Armaor writes wait for the production manager.
The agent lists Armaor delivery notes, finds the matching invoice in the ERP, and sets the invoice number on each delivery note.
Customer service asks in Teams or Claude. The agent reads the order's planning and progress in Armaor and the delivery date in the ERP, and answers. Nothing changes, so nothing waits.
A new customer opened in the ERP is created in Armaor with its sites, or the other way round. Creating runs on its own; deleting is never granted.
Priority and the other systems are connected as your own applications: on your server through the same connector, or in the cloud. Tell us which ERP you run and we will check its API with you.
Armaor's own log shows that the API user changed an order. It cannot show which agent did it, for which person, or who approved it. Contro1 records that for every call, in Armaor and in every other system the agent uses:
The person the agent worked for, and their request in their own words.
Its own identity, its owner and its department. Not a shared Armaor user.
The Armaor operation and the inputs it ran with.
Each approver and when, or that the action ran on its own because the policy allows it.
The result the connector reported from the server, kept apart from what Contro1 authorized.
Calls outside the agent's grant, such as deleting an order, are blocked and recorded too.
Every Armaor action you allow is available two ways, with the same grants, approvals and record.
Over MCP, for AI clients: add the Contro1 MCP address to Claude, ChatGPT, Copilot, Cursor or Claude Code, or connect an agent with the Contro1 CLI. The agent sees only the Armaor actions it was given.
An agent listing this month's orders. Path and query parameters go in by name; a request body goes under "body".
Through the Contro1 API, for your own programs, scripts or automation tools: call the same Action with an Agent Credential. Use it to pull lists out of Armaor (orders, planning, stock, delivery notes) and to push lists in (BBS lines, products, clients, stock entries).
The Action ids above are the ones Contro1 gives the Armaor operations; your agent gets the exact list from list_actions. An Action that needs approval answers awaiting_approval first and runs only after the approvers say yes.
From your first message to the first approved call. Most of it is one session with your IT person.
The server, its Windows version, and the port the Armaor Web API answers on. We turn on on-prem applications for your organization.
We bring the Armaor operations already reviewed, each with its effect and risk. You check them against your version and publish. Armaor then appears in Apps.
Download a one-use setup file in Contro1, copy it to the server and run three commands as an administrator. The server needs no browser and no sign-in.
In Access, open the agent's capsule, drag Armaor in, allow the actions it needs, and mark which ones wait for which people.
Add the MCP address to the AI client, or use an Agent Credential. Ask for this month's orders, and check the call in Activity. Then add writes, with approval.
| Question | Answer |
|---|---|
| Does Armaor go on the internet? | No. The connector calls it on the server or the plant network. Only outbound HTTPS to api.contro1.com leaves the network. |
| Do we change anything in Armaor? | No. Contro1 uses the Armaor Web API as it is. Nothing is installed inside Armaor. |
| Can an agent run anything else on the server? | No. The connector runs only the reviewed Armaor operations in its setup file. It is not a remote shell and not a VPN. |
| Can an agent delete orders? | Only if someone grants that action. We recommend never granting deletes to agents. |
| What if the connection drops during a write? | The write is marked uncertain and never retried on its own. A person checks Armaor and decides. |
| Who sees Armaor data? | The inputs and the answer of each call pass through Contro1 so it can check policy and return the result to the agent. The Armaor address and any key stay on your server. |
| How do we stop it? | Remove the agent's grant in Access, or stop the connector service. Calls stop at once. |
Not a public one that we know of, as of October 2026. Contro1 serves the Armaor Web API's operations as tools on the Contro1 MCP server, so Claude, ChatGPT, Copilot, Cursor or your own agent can use Armaor, each action allowed per agent and the important ones approved by a person.
Armaor installations can include the Armaor Web API, a REST API on the Armaor server. At our first install it exposed 68 operations: orders, BBS lines, planning, production, tags, traceability, stock, clients, sites, suppliers, products, deliveries and factory data. Ask Ariadis whether your version includes it.
Install the Contro1 connector on the Armaor server, publish the Armaor operations in Contro1, give your agent the actions it needs in Access, and add the Contro1 MCP address to Claude or ChatGPT. The agent then calls Armaor actions as tools, and the connector runs them inside your network.
Yes. One agent can be given Armaor actions and Priority actions, each with its own approvers. For example, it can read a confirmed sales order in Priority and create the order in Armaor, or set Priority invoice numbers on Armaor delivery notes. Every call in both systems is in one record.
No. The connector on the Armaor server only makes outgoing secure connections to Contro1. Armaor stays off the internet and nothing is opened to incoming traffic.
Only if you allow it. Each Armaor action is allowed per agent, and you choose which ones run on their own and which wait for one or more people. Putting an order in production is high risk and waits for approval by default.
Yes. Writes such as replacing an order's BBS lines, creating products, clients or stock entries are Actions you can call over MCP or the Contro1 API, with approval where you want it. Lists come out the same way: orders, planning, cutting tags, stock and delivery notes.
Windows Server 2016 or later, Linux with systemd, or macOS. It runs as a service. The first Armaor install ran on Windows Server 2025.
Give AI agents access to internal APIs and on-prem apps without a VPN or inbound ports, with per-agent permissions, approval for risky writes and audit.
Use your OpenAPI spec to give AI agents controlled access to a private API. Choose operations, approve sensitive writes, run calls through a private connector.
A practical framework for deciding which AI agent actions need human approval - with concrete examples across support, finance, and ops.
Choose the applications your organization approves, decide who may do what, and connect one MCP. Every person and agent gets exactly their access, and every action is recorded on their name.
Zero Trust for AI agents means every agent action is tied to identity, least agency, human approval, traceability, and signed evidence before it reaches business systems.