- Company
- Procol (procol.ai), enterprise procurement software
- Founded
- 2018, India; Series A
- Customers
- Large enterprises
- Product in scope
- Clara, an AI agent system for procurement operations that runs on defined instructions
- Team in the pilot
- The product team: product managers and the engineering lead
- Sources
- The product team's email, chat, issue tracker and meeting notes, read-only
- Goals formed
- A stable Clara release for enterprise customers; a closed feedback loop with pilot clients
- Status
- Pilot in progress; no results published yet
The company and its world
Procol is an Indian company that builds procurement software for large enterprises. It was founded in 2018 and has raised a Series A. Its customers run sourcing at scale: requests for quotation, supplier auctions, negotiations and the approvals that sit around them.
Part of Procol's product is Clara, an AI agent system for procurement operations. Clara runs on defined instructions. One set of instructions might guide suppliers through an auction; another might take them through an RFQ from invitation to submission. In a conversation with us, a senior product manager at Procol described what running Clara in production looks like:
- Many tool calls at once. Clara's agents call many tools in parallel, and those calls sometimes burst.
- Guardrails on restricted data. Clara must never share what a vendor should not see, such as the lowest bid in an auction.
- Evaluation and monitoring. The team uses third-party evaluations and error monitoring on the places where things break.
- Small rollouts first. Clara went out to three or four users first, and the team refined it from their feedback.
- Fast product, real gaps. The product moves quickly, and many gaps are found in production. Client teams run dry runs and send feedback.
This is a well-run AI product team. The question it faces is common to every company that ships agents: when signals arrive from everywhere, which one matters most today, and who owns it?
The problem before GeniOS
Each of Procol's tools does its own job well. The evaluations report how Clara behaves on a test set. Error monitoring shows where a call failed. The issue tracker holds the sprint. Client feedback arrives by email or in a call. Decisions are made in chat and in meetings. No single tool sees all of it, and no one person has the time to join it every day.
| Where the signal lives | What it tells the team | What it cannot tell them |
|---|---|---|
| Evaluations | How Clara performs on known cases | Which enterprise client is affected this week |
| Error monitoring | Where and how a call broke | That the same pattern was reported by a client last week |
| Issue tracker | What is planned in the sprint | That a fix date was promised to a client and is not planned |
| Client email and calls | What a client's dry run turned up | Whether anyone has picked it up |
| Chat and meetings | What the team decided | Whether the decision was signed off and recorded |
In a product that moves this fast, big failures get caught. The small, connected things are the ones that slip: a client's dry-run note that sits in one inbox, a failure that looks new each time it appears, a date said out loud in a call that never reaches the sprint.
How Procol connected its tools
The pilot started with the product team's own working tools. Clara's runtime and every client's procurement data stayed out of scope.
- Choose the product team's sources
Email, chat, the issue tracker and meeting notes. These are where client feedback lands, where failures are discussed and where dates and decisions are made.
- Read-only
Every source was connected with read access only. GeniOS reads and changes nothing, and any source can be disconnected at any time.
- No access to bids or client procurement data
GeniOS does not need to see bids, auctions or supplier submissions. Clara's guardrails stay where they are, and GeniOS works from what the product team writes and discusses.
- Permissions agreed first
We went through the exact permissions for each source with Procol's team before anything was connected.
- Three or four users first
The pilot began with a small group: product managers and the engineering lead. It is the same way Procol rolled out Clara, and for the same reason: refine from real feedback before widening.
How GeniOS formed the goals
GeniOS read the team's planning threads, release discussions and client correspondence, and drafted the goals the team was already working toward. The product managers then corrected them.
| Goal | Where it came from | What GeniOS checks against it |
|---|---|---|
| A stable Clara release for enterprise customers | Release threads, sprint planning and incident discussions | Failures that keep recurring, fixes promised but not planned, changes waiting on sign-off |
| Close the feedback loop with pilot clients | Client emails, dry-run notes and call notes | Client feedback with no owner, no reply or no ticket |
Two goals is a small number on purpose. A pilot that checks everything against two clear goals gives the team a short, trustworthy list in its first weeks.
The situations GeniOS picked up
These are the kinds of situations the pilot is built to surface, each checked against the two goals.
Dry-run feedback nobody owns
A client team runs a dry run of an RFQ flow and sends notes by email to one product manager, who is travelling. The notes describe a step where suppliers were confused. No ticket exists, and nobody has replied to the client.
A failure pattern that keeps coming back
Error monitoring shows a failure when Clara's tool calls burst during an auction. The same pattern was raised in chat two weeks earlier and closed as a one-off. It has now come back in other flows, each time looking new.
A promised fix date that is not on the sprint
On a call, someone tells an enterprise customer a fix will ship by a given date. The call notes record the promise. The issue tracker has no item for the fix in the current sprint.
A guardrail change that needs sign-off
An engineer proposes a change to how Clara handles restricted bid information. The change is merged for review, but the sign-off the team requires for guardrail changes is not recorded anywhere.
The intelligence, and what happened next
Each situation reaches one person as a piece of intelligence: what happened, what to do, why it matters to the goal, who owns it and by when. Each ends with Delegate, Done, Later or Not relevant.
| Situation | Sent to | Answer | What happens next | Closes on |
|---|---|---|---|---|
| Dry-run feedback with no owner | Product manager for the client | Delegate | A Reply Drafter drafts an acknowledgement to the client; the PM approves it and opens a ticket | The reply in email and the ticket in the tracker |
| Recurring failure pattern | Engineering lead | Done | Stays open until one ticket links every occurrence and is planned | The linked ticket in the sprint |
| Promised fix date not on the sprint | Product manager | Delegate | Passed to the engineering lead to plan, or to agree a new date with the customer | The sprint item, or the customer's reply to a new date |
| Guardrail change without sign-off | Engineering lead | Delegate | A Scheduler proposes a short sign-off review; the lead approves the invite | The sign-off recorded in notes or email |
| A test client's note already handled in a meeting | Product manager | Not relevant | Dismissed; GeniOS learns where that kind of note is resolved | Closed by the owner |
Approval before anything is sent. GeniOS thinks and delegates; the agents draft. Nothing goes to a client or a colleague until a person on Procol's team approves it.
Closed on proof. An item marked Done stays open. It closes when GeniOS finds the ticket, the reply or the recorded sign-off.
Where GeniOS stops. Clara keeps running procurement operations. The evaluations and error monitoring keep measuring it. GeniOS sits above all of that and decides what matters across it, for whom and by when. An AI agent may know how to execute a task. It may not know whether that task still matters to the company. The use case on AI agent oversight covers this in more depth.
What changed for the team
The pilot is still running, so this section describes what the team works with day to day. It does not report measured results.
- Client feedback has an owner from the day it arrives. Dry-run notes stop sitting in one person's inbox.
- Repeated failures read as one problem. A pattern seen in error monitoring, chat and a client email shows up as one situation with one owner.
- Promises meet the sprint. A date given to an enterprise customer is checked against what is planned.
- Guardrail changes carry their sign-off. The team sees which changes are waiting on review before they ship.
Any figures from the pilot will be published together with Procol.
The rollout, week by week
| Week | What the team does | What GeniOS does |
|---|---|---|
| Week 1 | Three or four users connect their sources read-only and review the drafted goals | Reads recent history and drafts the two goals |
| Week 2 | Users answer every piece of intelligence and correct owners | Learns who owns which client and which part of Clara |
| Week 3 | First delegations to a Reply Drafter for client acknowledgements, every draft approved | Closes items only on the sent reply and the ticket |
| Week 4 | A Scheduler for sign-off reviews; the team reviews where people stepped in | Raises guardrail and release situations ahead of the release |
| Week 5 on | Feedback to us, in the same loop Procol's clients use for Clara | Keeps learning from answers; widens to more of the team when the list is trusted |
What is next
After the pilot group trusts the list, the next step is to widen it to more of the product and client-facing team, so feedback from every enterprise customer reaches an owner. Procol and GeniOS will publish what the pilot shows together.
If your team ships AI agents and the signals about them arrive from everywhere, read why AI agents fail in production, then book a call or contact us.