The point
The work was never a chatbot problem.
A buyer does not need a freer prompt. They need a controlled operating surface. In Esolbay, the agent sees the current business object, the relevant supplier conversation, the files that belong to it, and the actions it can safely execute. The rest of the company is not context.
Domain
One procurement lifecycle, explicit business objects.
Esolbay models the lifecycle as real domain state: requisitions, tenders, suppliers, bids, awards, technical evaluations, orders, policy, email, messages, files, audit, and events. That matters because AI can only be useful when the product knows what kind of work is happening.
- 01
A requisition captures demand, files, ownership, budget, items, and policy state.
- 02
A tender turns approved demand into supplier-facing work, with groups, items, providers, dates, and approval gates.
- 03
Publishing the tender creates one award context per supplier, so each supplier conversation is isolated.
- 04
Inbound supplier mail is resolved back to the right award, stored as evidence, and used to update the bid only through allowed actions.
- 05
Evaluation reads across awards, but writes back to evaluation records, evidence, and controlled award decisions.
- 06
Awarding turns the decision into downstream order work without losing the trail.
Boundary
Bounded contexts are where the agent gets its shape.
A requisition context can prepare demand and move it toward approval. A tender context can structure supplier-facing work. An award context can handle one supplier response without touching the offer from another supplier. An evaluation context can compare awards, but it cannot edit arbitrary bids.
This is the important design choice: the model does not receive the whole company and then promise to behave. The product gives it the right slice of the world and the small set of actions that belong there.
Supplier loop
Supplier messages become workflow evidence.
Inbound email is not treated as free text floating beside the product. Esolbay resolves the message to the right award, links the email and attachments to that context, records the event, and then lets the award agent react inside that boundary. If the supplier is ambiguous, the workflow asks for selection before continuing.
That gives the buyer a practical result: the supplier thread, the bid, the tender, the award state, and the eventual decision remain connected.
Approvals
Approvals are blockers, not copy in a prompt.
Procurement has policy. Requisitions and tenders move through approval workflows that can create human tasks and pause the transition. The agent can help prepare the work, but the product keeps authority where the organization placed it.
Evaluation
Technical evaluation needs evidence.
Esolbay can evaluate criteria across supplier awards, but the result is not just a paragraph. The workflow creates evaluation runs, criteria records, evaluation records, scores, justification, and evidence references from files, email, or supplier messages. If the evaluation cannot point to auditable evidence, it should not be trusted as an operational decision.
Result
AI became part of the operating system, not a layer on top.
The outcome is not a generic assistant. It is procurement work with bounded context: domain actions, supplier communication, approvals, evaluation evidence, and audit trail moving together. That is the difference between a model that sounds useful and software that can move a workflow.
The rule: scope the work before adding the agent.
Start with the business object. Define the files, systems, owners, review points, and allowed writes. Then let AI operate inside that boundary.
Talk to Ekairos