The flagship ABAII Purchasing Agent turns intake — free-form Polish emails, scans, site notes — into a complete, supplier-sourced draft order in SAP Business One. Nothing commits until the manager approves.
In a mid-sized company, the departments that move documents — purchasing, HR, finance, sales support, reporting — share the same structural weaknesses. The CEO pays for all of them.
Every growth step in volume demands a proportional step in clerical staff — and that staff is increasingly hard to hire and retain.
Which supplier delivers on time, how this client's invoices are coded, where last quarter's numbers actually came from — when the person leaves, the department forgets.
Data is born in one place, re-typed in another, corrected in a third. Errors compound quietly until they surface as cost.
Commitments, exceptions, and risks are discovered in month-end reports — not at the moment decisions are made.
The department director — the person hired for judgment — spends the day chasing, correcting, and re-keying instead of deciding.
ABAII's answer is not a tool for one task. It is a way to run the department: agents execute the repeatable, document-driven work inside your own systems, and the department's manager supervises the agents exactly as they supervise people today — through approval. The manager keeps every decision that matters, and stops doing everything that doesn't.
The unit of automation is not a task; it is a department. Five solutions — each independently implementable, each supervised by its own manager, each adapted to your processes and systems of record, never the reverse.
A department-wide solution: agents take over the repeatable, document-driven work of the purchasing department — under the purchasing manager's approval, inside SAP Business One — with scope shaped per client from the department's full problem landscape, including upstream planning problems like building and maintaining the procurement plan.
The procurement plan is born upstream and degrades on the way: a tender bid with rough per-unit costs, refined by a project manager, folded into the plan only at the end — disrupted by imprecise data and human error at every handoff. Around it sits the daily grind: free-form requests by email, missing details chased sender by sender, supplier knowledge held in individual heads, offers compared under time pressure, exceptions and urgencies displacing planned work.
Purchasing weaknesses land directly on margin: prices unchecked against history, commitments invisible until invoices arrive, maverick and duplicate buying, project delays traced back to late materials, and a sourcing capability that walks out the door with each departing buyer. The department cannot scale volume without headcount — and the owner has no reliable, current picture of committed spend.
Free-form Polish material-request emails become supplier-sourced draft purchase orders in SAP Business One — sender verified against the authorized-employee list, missing details chased automatically, offers benchmarked against the item's 12-month median, and a person approving before anything is committed.
THE FLOW, IN MOTION — § 03 · THE FULL SPECIFICATION — § 04Continuous, read-only assembly of the department's open-commitment picture, directly from SAP data. It answers the owner's question named above: what has the company committed to spend, right now?
READ-ONLY · ZERO WRITE RISK · AUTONOMY LADDER L0 BY CONSTRUCTIONA material request arrives by email into the department's intake mailbox — one email becomes one task.
The sender is verified against a manager-owned, versioned authorized-requester list. Unverified senders never get a silent reply — the case routes to the manager's exception queue.
The request is read and structured — item, quantity, unit, needed-by date, delivery location, project and cost assignment — from free-form Polish text and attachments. Missing details trigger a bounded clarification loop: by default two rounds, then it becomes an exception.
Sourcing runs on a policy fork. A usable price basis — an active framework agreement, a loaded price list, valid recent history — goes straight to a draft order. Otherwise, a bounded RFQ round: by default three whitelisted suppliers, a three-business-day offer window.
Offers are benchmarked against the item's 12-month median purchase price. Missing benchmark data tightens the control, never loosens it — an unbenchmarkable line always routes to human approval, regardless of amount.
A draft purchase order is created as a proper SAP Business One object, visible to buyers in SAP itself — never a side spreadsheet. It is promoted to a live purchase order only at commit.
The purchasing manager approves in the Manager Console, seeing the full picture: the drafted order, supplier selection rationale, price benchmark result, framework and price-list status — and, for stock-managed items, an advisory real-time stock read.
On approval, the order commits to SAP as a real purchase order and is sent to the supplier; the requester is notified. Every step is on the audit trail.
The same model, applied to four more departments: the agent takes over the repeatable, document-driven work; the department's own manager approves it. Each is scoped per client through the Discovery Workshop — the problem, the design, and the delivery path.
Behind every salesperson stands a back office of unglamorous work: inquiries arriving free-form and incomplete, quotes assembled from price lists and past offers, CRM records maintained — or not — by hand, follow-ups slipping. Sales knowledge lives in mailboxes and heads.
Slow quote turnaround loses winnable deals; a stale pipeline makes the revenue forecast a guess; the order desk caps how many inquiries the team can handle. Revenue growth demands back-office headcount that adds no selling capacity.
Free-form Polish customer inquiries become registered, structured inquiry records and drafted quotes — completeness checked and missing details chased automatically, prices drawn from current price lists and the customer's quoting history with margin computed per line, and a person approving before any quote is issued.
The month is a cycle of document chasing: invoices captured, coded, and matched against orders and receipts; payment runs proposed and checked; discrepancies bounced back; the close pressed against the same deadline every month. Exception handling — the interesting part — is buried under volume.
The cost shows up as a slow close and a cash position known with a lag; the risk as posting errors, missed discounts, weak defenses against irregular invoices, and audit preparation as an annual emergency. Finance headcount scales with document volume, not with the company's ambition.
Supplier invoices captured — including via the KSeF government API — coded, matched against purchase orders and goods receipts with deterministic validation before any write, and assembled into a payment proposal a human reviews. Every step is on the audit trail.
A small team carrying a wide administrative load: onboarding and offboarding run from checklists that live in someone's memory; leave, absence, and personnel documentation demanding constant, error-intolerant upkeep; a steady stream of policy questions interrupting everything else. The work crowds out the part of HR the company actually needs — finding and keeping people.
A hiring bottleneck in a tight labor market, compliance exposure in employment documentation, and an administrative cost that grows with headcount precisely when the company is trying to grow without it. When HR knowledge sits with one or two people, their absence stalls processes company-wide.
One agent-maintained register of expiring obligations — medical exams, safety trainings, licenses and qualifications, permit and residence dates, contract limits — monitored against configured lead times, renewals chased and referrals drafted, every outbound action passing the HR manager's approval. A lapsed credential legally stops work; this capability carries no employment-decision content.
Whoever owns reporting — a controller, an analyst, often a lone spreadsheet virtuoso — spends each cycle pulling data from systems that don't talk to each other, reconciling versions, fixing what changed upstream, and formatting under deadline. The method lives in that one person's head and in fragile spreadsheet chains.
Decisions wait on numbers that arrive late, and confidence in them is never complete: figures differ between reports, and asking "why" triggers days of archaeology. The company is driving by the rear-view mirror — and its entire reporting capability is a key-person risk.
The recurring management pack assembled from governed, versioned mappings with full tie-outs — every figure provenance-tracked, every change versus the prior published version flagged, and the reporting manager approving before anything is published or distributed.
Every ABAII agent runs on the same infrastructure layer, built greenfield inside the flagship Purchasing Agent build and extracted for reuse. Core is a growing efficiency for multi-department clients — never a dependency, never an entry requirement. Each department solution is independently implementable; a second or third department reuses the same integration layer and knowledge base, each still supervised by its own manager through their own console view.
A triggering input — an email, a scheduled event — becomes one task.
The agent works it step by step. Every write requires a policy-issued, single-use token bound to that exact action.
Proper objects in your systems — with every step logged to an append-only audit trail.
Approval inbox, KPI dashboard, agent activity feed, exception queue.
Threshold matrices, escalation rules, per-action permissions. Changes are versioned and require client sign-off.
Claude-powered reasoning loops with deterministic guards — retry, timeout, fallback handling.
MCP connectors to ERPs, workflow systems, and email.
A local MS SQL Server store syncing ERP master data and process documents — with data-as-of timestamps on everything agents read.
An append-only record of every agent read and write, every model call, and every human decision.
No "super-approver" exists anywhere in the system. On a multi-department installation, no manager sees another department's queue, and no agent reads another department's data.
Automation is easy to promise. What a department needs is supervision that holds: a named person in command, and every decision reconstructable. The pairing is always one manager ↔ one department — a multi-department client has multiple managers of agents, never a single approver over everything. Every ABAII solution must pass three tests.
Exactly one named human owns the process outcome.
That human can see, approve, reject, or escalate agent actions. Nothing above their thresholds happens without their decision.
Any past agent action can be fully reconstructed: what was done, on what data, on whose approval, with what result.
The manager works from a single approval inbox. Every routed item shows the action, the drafted artifact, why it was routed — which policy rule fired — the source data with its as-of timestamp, and the agent's reasoning. Approve, reject with instruction, or escalate: nothing moves without the decision.
Dzień dobry, proszę o zamówienie 800 m kabla YAKXS 4×120 na obiekt K-12. Termin: do 12.08. Szczegóły w załączniku. Pozdrawiam
Autonomy is earned against measurable criteria — never assumed on day one. Every deployment starts at L1 or L2; moving up a level is a gated, signed decision — never silent drift.
A server at your location — Windows Server + IIS — in a strictly isolated network segment. Only declared paths are open: ERP API, LLM endpoint, and email platform outbound; HTTPS to the Console from a defined subnet. Nothing undeclared, in or out.
The AI layer is the Anthropic Claude family via commercial API — your data is not used for model training under commercial terms. A data-processing agreement is part of every deployment. Tool access runs over MCP, the standard interface between agents and business systems.
EU data residency by design, with GDPR-compliant processing.
The append-only chain holds metadata, hashes, and references, retained for the engagement's agreed horizon. Personal-data payloads live in a deletable store with per-deployment retention — payload-level deletion satisfies GDPR erasure requests.
Inbound email is treated as hostile until proven otherwise: sender identity verified against an authorized list — not just the display name — before the agent acts on any of it.
Every use case is classified. High-risk functions — employment decisions among them — get the enhanced regime.
Payment release is permanently out of agent scope. The agent proposes; a person releases money — always. No agent component ever holds bank credentials.
Agents prepare and organize; a human makes every hiring and employment decision. No action class ranks, scores, recommends, or filters people.
Every deployment starts at L1 or L2 on the Autonomy Ladder — nothing executes without explicit human approval. Inside the platform, every write requires a policy-issued, single-use token bound to that exact action: no token, no write. Higher levels exist, but each is a gated, signed decision against measured criteria.
No. Each department solution is independently implementable, and any of the five can be the entry point. ABAII Core — the shared platform underneath — is a growing efficiency for clients who add a second or third department, never a dependency or an entry requirement.
No, by design. The pairing is always one manager ↔ one department; a multi-department client has multiple managers of agents. No "super-approver" exists anywhere in the system — no manager sees another department's queue, and no agent reads another department's data. The same rule holds inside a department: per-salesperson approval routing is intentionally out of scope — one manager, one inbox.
No. ABAII does not offer ERP implementations, ERP customization, helpdesk, infrastructure administration, or bespoke application development. ABAII does exactly one thing: agentic AI infrastructure — agents, the platform they run on, and the supervision model around them. Deployment follows the drop-in principle: everything in the department can stay exactly as it is — the same ERP, the same email, the same approval habits, the same manager. Only one server is added.
No. Employment-related AI is a high-risk category under the EU AI Act, and ABAII treats it as such: agents prepare and organize, a human makes every hiring and employment decision, and no action class ranks, scores, recommends, or filters people. The HR Agent's v0.1 scope processes employee data only — never candidate data — and its only external write channel is email: it creates no ERP objects and touches no payroll system directly.
Never — as a product principle, not a limitation. The agent assembles the payment-run proposal; on approval, it creates the payment objects in SAP Business One as a deterministic transformation of what was approved; SAP's own payment mechanism produces the bank file; a person exports and releases it. No agent component ever holds bank credentials. And a bank-account change on any invoice forces a mandatory human escalation, regardless of amount.
No. It is the portfolio's only read-only-toward-ERP agent: it proposes, reconciles, and assembles — it never touches your books. Adjustments are proposed only from documented evidence, never from inference, and only the reporting manager approves them. Target-setting and budget negotiation stay human.
The default context source is a dedicated knowledge base synced from SAP Business One, with data-as-of timestamps on everything the agent reads. Where a decision needs current truth, the agent performs explicit, declared real-time reads — for example, the advisory stock read shown at approval. Nothing undeclared runs against your system.
Out of scope, by decision. The human fast path for urgent buys stays untouched, and phone- or messenger-borne traffic reaches an agent only when a person forwards it into a written channel — email is the bridge.
Integration is native: the Service Layer on 10.0 / HANA, with a DI API bridge for 9.3 / SQL. Documents are created as proper SAP objects — never side spreadsheets. Where workflows run in Webcon BPS, it is integrated over REST.
Polish-first. Requests, inquiries, and documents are read in free-form Polish, including attachments; supplier communication runs in Polish or English. A Polish version of this site is planned.
A paid, fixed-price Discovery Workshop is the first step: one to two days on site plus analysis. You get the department's problem landscape, a feasibility assessment, a KPI baseline, and a concrete pilot proposal. Any of the five departments — or a custom one — can be the entry point. We don't ask you to believe in AI; we ask you to look at four weeks of your own numbers.
BOOK A DISCOVERY WORKSHOP