Agent tools
Agent tools: make existing actions in your systems safely usable for AI agents.
Your systems can already create orders, check blocks and update accounts. Nexus makes those existing actions usable for AI agents, with fixed parameters, a version and an approval. Connected once, the same tool serves several agents and processes.
- SAP
- Salesforce
No two SAP systems are alike.
Most companies have invested heavily in SAP and Salesforce: custom objects and fields, flows, Apex classes, SAP customizing, their own OData services and APIs. That is where the logic behind your orders, prices and blocks actually lives.
An agent that only knows standard objects fails on the first real order. Nexus therefore works with your landscape as it is today.
From system component to controlled tool.
Read metadata
Nexus reads objects, fields, flows and Apex actions, plus OData entity sets, actions, function imports and custom APIs.
Propose tools
This produces draft tools with name, description and parameters, e.g. erp.salesOrder.create.
Narrow down
Your team defines which fields and values are allowed, whether the tool reads or writes, and which policy applies.
Test and approve
The tool is tested against your test systems and only becomes available in PROD after approval.
Low-code for the standard, code for the rest.
Both paths end in the same tool model, with the same approval and the same audit trail.
- Low-code
Generate from metadata
For objects, flows and services your systems already describe. Nexus proposes the tool, your team narrows down fields and values.
- Pro-code
Build your own tools
For logic that can’t be derived from metadata: several calls in one step, conversions, custom checks. Based on OpenAPI, code or an MCP server.
What Nexus reads from your systems.
Tool names are examples. Naming and scope follow your process.
Salesforce
- Standard and custom objects
- Fields
- Flows
- Apex actions
- crm.opportunity.read
- crm.account.update
SAP
- OData entity sets
- Actions
- Function imports
- Custom APIs
- erp.salesOrder.create
- erp.customer.check
- delivery_block.search
Other systems
- REST APIs
- OpenAPI specifications
- MCP servers
- Webhooks
One process model, different system landscapes.
Process packs work with business capabilities rather than fixed APIs. For each customer, those capabilities are mapped to their systems during the project. The flow stays the same; the wiring underneath changes.
| Business capability | Landscape A (example) | Landscape B (example) |
|---|---|---|
| crm.customer.read | Salesforce account with a custom object for customer tiers | Salesforce account enriched with SAP business partner data |
| erp.customer.check | Credit and block check in S/4HANA via standard OData | In-house API service with custom block logic |
| erp.salesOrder.create | S/4HANA sales order via standard OData service | SAP ECC via Integration Suite |
| crm.opportunity.update | Opportunity update followed by a Salesforce flow | Opportunity update via Apex action |
Illustrative example, not customer data.
Every tool stays under control.
Versioned
Changing a tool creates a new version. Agents use the version they were tested with.
Approved
A tool is only usable in PROD once approved. You decide who approves.
Policy-bound
For each tool and agent, policies define read, write or approval-only.
Reusable
One tool serves several agents and process packs, with changes and audit in one place.
Where the limits are.
A tool can only do what the interface underneath allows. If a step has no service and no API, there is no tool until an interface exists. Proposals from metadata are a starting point, not a finished result: scoping, values and tests are part of the project work.
What to plan for
- Technical users with narrowly scoped rights in each target system
- Write access only after testing and explicit approval
- Customer-specific mapping per system landscape
- RPA only as an exception when no interface is possible
Frequently asked questions about agent tools
Do we have to change our SAP customizing or Salesforce org?
Usually not. Nexus uses your existing objects, flows, services and APIs. If a step lacks an interface, we work out whether an existing service will do or a new one is needed.
Does the agent get full access to the system?
No. An agent only sees the tools assigned to it, with tightly defined parameters. Credentials never enter the AI model’s context.
What happens when an interface changes?
The affected tool is adjusted, tested and approved as a new version. Until then, agents keep working with the version they were tested with.
Does this work with SAP ECC?
Yes, as long as the required functions are reachable via services, RFC modules or your integration platform. We check this for your specific process.
Read on
Integrations
What is deeply integrated and what joins via API, events or MCP.
Approvals & rules
When a tool may be used without approval.
Process packs
Business solutions mapped onto your tools.
- Insights
How AI agents write to SAP safely
Identity, policies, approvals and idempotency when agents create orders in SAP.
Start with one process.
30 minutes · free · with a senior architect. You get a verbal initial assessment and concrete next steps.