Learn the client's SAP, then resolve it safely.
It starts with an assessment that maps how that client's SAP actually works into a knowledge graph. The agents reason over that graph, and every action they propose is gated by policy before anything happens. Tessera federates across your systems rather than replacing them.
Connectors to SAP (S/4, BW/4, CPI and BTP, IDoc, OData, RFC and BAPI), ServiceNow, and identity. Data is queried where it lives; copied only when necessary, within residency controls.
A SAP-AMS knowledge graph and semantic layer, per-client resolution memory, and retrieval indexes that ground every recommendation in your own history.
Config-driven agents orchestrated through supervisor and graph patterns, with a risk-tiered action model and human-in-the-loop approval queues.
Command center, copilot surfaces, assessment reports, governance and audit dashboards, and cost attribution.
A ticket carries its full context.
Incidents, IDocs, orders, configuration, partners, plants, error signatures, and business KPIs live in one semantic model. So when a delivery block arrives, an agent already knows the order, the partner, the interface, the recurring signature, and the KPI it threatens, instead of rediscovering it.
Built during the assessment: 46 entity types and 50+ relationships, plus per-client resolution memory that compounds with every fix.
An agent proposes. Policy decides.
A language model is good at reading a messy ticket and reasoning toward a fix. It is the wrong thing to trust with a production change on its own. So every action an agent proposes passes through a deterministic policy engine before anything happens.
Agent proposes
The agent reads the ticket and graph context and proposes a specific action with a confidence score and cited evidence.
Policy engine
Deterministic rules check it:
- action on the allowlist
- segregation of duties
- environment permitted
- confidence above threshold
Decision
Auto-resolve, require human approval, or block and escalate, by risk tier. Every decision is recorded with its inputs and the rules applied.
The policy engine is deterministic and is not overridable by model output or prompt content.
Safe to put in your client's production.
Action is gated by risk. Higher risk means more oversight, never less. This is what lets an SI put agents near production SAP at all.
| Risk | What the agent does | Examples |
|---|---|---|
| Low | Auto-resolve within allowlist | Password reset, known IDoc reprocess |
| Medium | Act and log | Job restart, queue clear |
| High | Require human approval | Role change, credit release |
| Critical | Block and escalate | Production config, security grants |
- Human-in-the-loop approval queues, with shadow mode before any execution
- Role- and attribute-based access, with segregation of duties enforced
- Source attribution and confidence on every recommendation
- Immutable audit of every agent decision and human approval
- Per-agent and global rollback and kill switches
- Per-client data isolation; one client's knowledge is never shared with another
What makes agents safe to deploy.
Reaches your systems
Federated access to SAP (S/4, CPI and BTP, IDoc, OData, RFC, BAPI), ServiceNow, and identity, querying data where it lives.
Knowledge that stays
Every validated resolution becomes reusable, versioned, and attributable, isolated to each client tenant.
Acts within limits
Calls SAP via APIs, BAPI, and OData, with RPA only where no interface exists, never beyond the allowlist.
Where you need it
SaaS, private cloud, or fully isolated for regulated estates, one control surface everywhere.