Procurement AI agent · Intake
Intake and Orchestration AI Agent
Shape the buying request whatever form it arrives in, ask only the questions this one needs, route it to the reviews it actually requires, and leave every approval to a named procurement lead.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named lead
- Questions first
- After launch
- Agent Care
What this agent does
Routes the request, never approves it
In
- 01
A request arrives as an email, a form, a ticket or a corridor conversation, and it is taken in as it stands.
- 02
A request is read for what it is actually asking, before anyone decides which reviews apply.
Reason
- 03
A request is asked one question at a time, each one chosen because of the answer before it.
- 04
A request needing legal, security and data-protection reads has them opened together, not in turn.
- 05
A route is drawn where one review truly blocks another, and the dependency is stated rather than assumed.
Decide
- 06
A request that is really several requests is split, and each part goes to the people it needs.
- 07
A request that duplicates one already in flight for another team is joined to it, not started again.
Out
- 08
A request stalls, and the review it waits on and the person who owns that review are both named.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Intake, shaping and routing belong to the agent. Approval belongs to a named procurement lead, who clears the request and owns the decision from there.
Example workflow
One request, arrival to clearance
- 1Request receivedAn email, an intake form, a ticket, a chat message or a line on a spreadsheet
- 2Request read and shapedWhat is being bought, for whom, against which contract and by when the requester needs it
- 3Reviews identified and sequencedWhich reviews apply, which may run together and which one waits on another
- 4Controls appliedCompleteness checks, duplicate checks, threshold checks and routing confidence
No human action required
Stages 1 to 4 run unaided, and nothing is approved at any of them — the agent is routing, and the procurement lane opens at the routing gate.
Goes to the procurement lead to clear.
Adds a category read first.
Procurement review
The request is held with the answers given, the reviews opened and who each one waits on.
Clear · Reroute · Send to category review
Cleared — by the procurement lead
- 6Workflow and purchasing records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedRouting accuracy, review coverage, lead corrections and what the read found
Corrections
Each procurement-lead correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Approving a buying request of any size.
- Waiving a review a request has triggered.
- Ruling that a threshold has not been crossed.
- Closing a request as unnecessary.
Automation boundary
Agent acts unaided
- ✓Take the request in whatever shape it arrived.
- ✓Ask only the questions this particular request needs.
- ✓Open the reviews the request requires and run them in parallel.
- ✓Show where the request is waiting and which person must act next.
Nothing is approved except by a named procurement lead, inside the boundaries agreed.
- Deciding which team owns a shared purchase.
- Telling a requester that no review applies.
- Choosing which supplier a request goes to.
- Changes to routing rules or review thresholds.
Example output
One buying request, annotated
Our operations workflow agent orchestrates business processes across systems; this one shapes a human request before any process starts, and below is one request as the agent leaves it.
Intake output · single request
Illustrative example- Request
- Software for one team
- Recorded as
- Arrived as an email thread
- Requester
- Shaped, not approved
- Evidence of record
- Intake record, 3 August 2026
- Confidence
- Held uncleared
- Held for
- The procurement lead, by name
As received
Read off the request as it arrived and the answers the requester gave, and it claims nothing past those.
What the record holds
- The request as sent
- The answers given
- The reviews opened
Why no clearance here
Clearing a request is a judgement a named procurement lead owns.
What the score decides
Below the configured threshold the request collects a category read before the lead sees it.
Action
ClearRerouteSend to category reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every request
From wherever it arrived
Where the evidence is used
Where a request was routed wrongly and the buy has already happened, the lead reopens it with its intake trail attached, the missed review is run late, and the case joins the suite.
The request arrives shapeless
Somebody wants something and does not know whether it needs legal, security, data protection or a new supplier — and the form assumes they do.
What was checked, and not found
No rule consulted requires a buying request to be routed any particular way: intake design is policy a company writes for itself, so which reviews a request triggers and the order they run in are choices rather than requirements. What is measured here is your own policy and whether a request met it.
Build an evidence trail
The request, the route it took and the person who owns it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Intake channels
- web forms
- chat apps
- Service desk and ticketing queues
Workflow and approvals
- ServiceNow
- Jira
- Asana
- Approval steps and task queues
Purchasing systems
- SAP Ariba
- Coupa
- Jaggaer
- Requisitions and the approved catalogues
Agent
Intake and orchestration
- Takes the request
- Shapes and routes
- Holds for the lead
Reviews and reviewers
- Legal
- security
- data protection
- Finance and the category owners
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six junctions between the model and the reviewers
Six junctions on one line, the last the narrowest. What runs on is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a route may stand
- L3
- Leaves the clearance to a procurement lead
- L4 – L5
- Keep the request and the route behind it
- L6
- Routes the request to a person when signals degrade
How Nestack evaluates it
Evaluate the whole intake — not only the route that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the route a requester is given
- E1Final-output evaluationDid the route record the reviews the request actually required?
- E2Step-level evaluationDid the agent read the right request, the right answers and the live rules?
- E3Tool evaluationDid it read and write the correct request and the correct workflow step?
- E4Confidence calibrationDo low-confidence routes attract more corrections from the lead?
- E5Slice evaluationHow does performance change across specific request types?
- E6Business outcomeHow many requests needed a correction before the lead would clear them?
Floor — the route a request ends up on
Failure modes
Where each failure originates in the agent
Seven failure modes, each set at the stage it first becomes visible.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- OM-03
Stale routing rules read
The rules read are not the ones now in force.
Stage gathers
The request, the answers, the rules and the dates
02 · Reasoning
2 modes
- OM-04
Review skipped as not applicable
A review that applied was scored as not needed.
- OM-06
Superseded routing rules read as live
A retired rule set is worked as the current one.
Stage proposes
The request, the reviews and the order they run in
03 · Tool / write
2 modes
- OM-02
Thin route passed forward
A request moves on without the category read.
- OM-05
Request bound to the wrong team
The request is filed against another team.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- OM-01
Routed to nobody
The request goes to a name that no longer answers.
Stage returns
The route a requester waits on and a lead clears
05 · Change / Version
1 mode
- OM-07
Silent routing drift
A review rule changes while open requests keep the old one.
Stage tracks
Model, prompt, routing rules and form dates
- Sev-1 · a request cleared with a review open
- Sev-2 · a request routed to nobody at all
- Sev-3 · signals degrade, request held back
Affected slices
First-time types absorb the reroutes
A type-level routing figure can read clean while first-time request types carry most of the routes that had to be redone. Nestack reports the reroute rate by request type, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| First-time request types | 9.0% | 3.7× | Review | |
| Multi-review requests | 6.4% | 2.6× | Review | |
| Cross-team shared buys | 4.0% | 1.6× | Watch | |
| Catalogue re-orders | 1.7% | 0.7× | Normal |
Bar: reroute-rate lift vs. catalogue-re-order baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a request routed to nobody costs
A cycle ends when the request routed to nobody is a standing case. That suite is what the next intake cleared is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Reroute rate rises on first-time request types.
- 02
Diagnose
The buying request that came in as a message to somebody who left, and sat there, is worked backwards until one cause is left standing.
- 03
Improve
Changes leave numbered, and the requests that forced them are filed underneath.
- 04
Verify
One request case still failing is enough to stop the release.
- 05
Learn
One case joins the suite, one line joins the routing rules.
Learn → Detect
The return edge. The next request is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, intake and routing logic, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Intake discovery and automation-boundary definition.Week 1
- 02Email, workflow and purchasing sources.Week 1, Week 2
- 03Request shaping and question-dependency route mapping.Week 1, Week 2
- 04Request capture and channel normalisation.Week 2
- 05Question sequencing and review binding.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Procurement review workflow.Week 3, Week 4
- 08Workflow and purchasing integration.Week 5
- 09Routing and completeness cases.Week 4, Week 5
- 10Guardrails and routing controls.Week 4
- 11Request-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne team, one request type | ProductionProduction intake workflow | AdvancedMultiple teams / entities |
|---|---|---|---|
| Introduced at Pilot | |||
| Request shaping to your rules | ✓ | ✓ | ✓ |
| Named procurement-lead clearance | ✓ | ✓ | ✓ |
| Request-population baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by request type | — | ✓ | ✓ |
| Routing review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Workflow-and-form integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-review orchestration | — | — | ✓ |
| Cross-team request packs | — | — | ✓ |
| Large request volumes | — | — | ✓ |
| Multi-team routing controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, request volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your live request channels and the shapes they arrive in
→Request capture and channel mapping
Week 102Representative requests from a recent buying period
→Channel capture, question logic and the routing baseline
Week 203Your review owners and the teams they sit in
→Review mapping, question logic and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Channel, workflow and purchasing source assessment, then integration setup
Week 205Requests you would not want traced
→Routing cases and failure-mode testing
Week 406What no intake form may settle
→Confidence scoring, review routing, guardrails and release controls
Week 307A named procurement lead who clears the request
→Release to the procurement lead, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Read the bands as measurements, not decoration. Two share week five because that is how they run.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Intake discovery, review mapping and the automation boundary
W2Channel and workflow integration and the request baseline
W3Question sequencing, routing logic and release controls
W4Evaluation suite, routing cases and failure-mode testing
W5Purchasing integration, pilot requests and targeted corrections
W6One intake month run under the procurement lead, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for, and two bands genuinely share week five.
- At the end of W6
- When the routing record validates, Agent Care takes the agent on.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Procurement AI agent
Build an intake agent around the buying request your last form never fitted.
Show us one buying request that reached the right desk late and the form it was asked to fill in first. Send it as it arrived, and we will show you the questions it should have been asked and the reviews it should have opened. A request nobody chased comes back as a finding.
- Typical delivery
- 4–6 weeks
- Deployment
- Your live channels
- Named lead
- Questions first
- After launch
- Agent Care available
Nestack Agents · Intake and orchestration
AGT-PR-07 · Agent Care available after launch