Flex Credits & AI Architecture
Agent usage is metered in flex credits. Architecture choices are now commercial choices - this module teaches how to make them well.
Welcome
Workday's AI isn't free at the point of use. Agent activity is metered, and the unit of measurement is the flex credit. That changes what "a good design" means - an elegant architecture that burns credits unnecessarily is not a good architecture any more.
This module is for the people whose decisions shape the bill: architects, solution leads, senior consultants. Engagement managers and commercial colleagues should read it for awareness - the patterns here are the ones you'll be asked to cost and defend.
By the end, you should be able to design an agent-rich solution that delivers the customer's outcome without a credit surprise in month four.
Learning objectives
What are flex credits?
A flex credit is Workday's consumption-based commercial unit for AI features. Customers don't pay per agent, per user, or per seat - they pay for metered usage, priced in credits, against an allocation they've either negotiated or earned through their contract.
Allocated
The customer holds a credit balance, typically negotiated as part of the Workday contract or as a named top-up.
Consumed
AI features draw down against that balance as they're used - by employees, managers, finance users, and so on.
Reported
Workday exposes usage so the customer can see which agents, which populations, and which workflows are spending credits.
The credit model means the customer's AI cost is a function of how they use it. Two customers on identical contracts will end the year with very different bills if one has deployed agents to the whole organisation and the other to a carefully scoped population.
Exact credit prices and per-agent consumption rates change on Workday's commercial cadence. This module deliberately avoids quoting specific numbers - they will be wrong by next release. Always check the current Workday flex credit rate card before committing a customer to a design.
How agents consume credits
Not every agent consumes at the same rate. The four variables that matter most are the agent's category, the user population, how often it's invoked, and how much data it touches per invocation.
Agent category
A light read-only insight agent that summarises or surfaces information consumes less than an action-taking agent that drafts content or configures a business process. Reasoning depth and output volume both matter.
User population
Credits scale with invocations, and invocations scale with users. An agent exposed to every employee behaves very differently from one exposed to a hundred recruiters.
Frequency of use
A once-a-quarter planning agent and a daily employee self-service agent may share a category but sit at opposite ends of the consumption curve.
Data volume per call
Summarising a 2-page policy is not the same as extracting obligations from a 400-contract portfolio. Input and output size are both priced in.
Customers will ask "how many credits will we use?" The honest answer is "it depends on these four variables - let's size them against your population and workflows". Anyone giving a flat number without that conversation is guessing.
Architecture decisions that drive consumption
These are the decisions an architect makes, usually early, that set the consumption curve for the whole deployment. Each one has a cheap option and an expensive option - both may be right, but the choice must be deliberate.
Where the AI runs in a workflow
Put the agent at the decision point, not at every step. An agent that runs once per case consumes less than one that runs on every status change in the case.
Batching vs real-time
Real-time invocation is powerful and expensive. Batch processing - nightly, weekly, on-trigger - delivers most insight workloads for a fraction of the credit cost.
Human-in-the-loop checkpoints
A checkpoint that makes a user confirm before re-running an agent prevents runaway loops. No checkpoint, and a frustrated user will re-invoke the agent until they get the answer they wanted.
Which agents are "on" by default
Every enabled agent is a potential consumer. Turn agents on because a named population has a named job to do with them - not because the feature exists.
Population scoping
Scope agent access to the population that will get value. A recruiter agent exposed to all managers consumes credits from people who'll never get a benefit from it.
Data scoping per call
Narrow the input. An agent that reviews "all open contracts" costs more than one that reviews "contracts flagged for renewal in the next 30 days". Same outcome, smaller bill.
Efficient vs expensive patterns
Three recurring pairs. In each, both patterns deliver the customer's outcome - but one does so with a much lighter credit footprint.
Pair 1 · Broadcast vs targeted
Expensive: broadcast deployment
Turn the agent on for the whole organisation on day one. Let adoption sort itself out. Every curious click consumes credits.
Efficient: targeted deployment
Deploy to a named population with a named outcome. Expand once you have usage data and a business case for the next cohort.
Pair 2 · Continuous vs event-driven
Expensive: continuous insight
Re-run sentiment, risk, or anomaly scoring every hour regardless of whether anything changed. Feels modern; costs a lot.
Efficient: event-driven insight
Trigger the agent on a meaningful event - new contract loaded, case opened, review cycle started. Same signal, fraction of the invocations.
Pair 3 · Full-corpus vs scoped
Expensive: full-corpus every time
Every invocation re-processes the entire underlying dataset "to be safe". Credit cost scales with corpus size, not user need.
Efficient: scoped per invocation
Pass only the records relevant to this user's question or this workflow step. Smaller input, smaller output, same answer.
If you can't articulate why an agent needs real-time, full-corpus, broadcast delivery, assume it doesn't. The default should be event-driven, scoped, targeted. Argue up from there, not down.
Quick knowledge check
Governance & budget guardrails
Credits without guardrails behave like cloud spend in 2014 - surprise bills, finger-pointing, and a knee-jerk freeze that kills adoption. The governance pattern is the same: named owner, monitoring, caps, escalation.
Named approver per agent
Every credit-consuming agent has a named owner on the customer side who approved turning it on. No orphaned agents.
Monthly usage monitoring
Usage reports reviewed monthly, with trend lines. The first unexpected spike is a conversation, not a crisis.
Soft and hard caps
Soft cap triggers an alert; hard cap throttles or disables the agent. Decide both thresholds during design, not after the first bill.
Escalation path
A defined route from usage anomaly to architect review to customer conversation. Written down, not improvised.
Who signs off a credit-hungry deployment?
Any agent forecast to consume a material share of the customer's annual credit allocation should go through a joint Kainos-customer review before activation. "Material" is defined by the customer's finance or platform owner, not by us. Our job is to surface the forecast; their job is to decide whether it's worth it.
The customer conversation
Credits confuse and alarm customers who are used to per-seat software. The conversation has to reframe the model before it discusses the number.
Frame 1 - Credits are elastic, not punitive
They let the customer pay for what they actually use. A pilot costs pilot-money. A full roll-out costs full roll-out money. They don't prepay for a capacity they might not use.
Frame 2 - Value per credit, not total credits
"We used 40% more credits than last quarter" is meaningless on its own. "We used 40% more credits and closed cases 22% faster across three business units" is a business conversation. Always lead with the outcome the credits bought.
Frame 3 - Controllable, not mysterious
Consumption is a function of architecture choices the customer can see and change. The Kainos AI Navigator includes a credit-forecast conversation at design time and a monthly usage review after go-live. Customers who feel in control don't panic at the bill.
"Credits let us tune the deployment to your population, not pay for capacity you don't need." · "Let's look at value per credit, not just credits." · "The rate card moves - here's what to check before we commit."
Red flags for architects
Patterns that, in our experience, burn credits disproportionately relative to the value they deliver. If you see them on a design review, challenge them.
- "Turn on every agent available." No named population, no named outcome - just activation for its own sake.
- Real-time on workflows that don't need real-time. Nightly batch would deliver the same answer at a fraction of the cost.
- Broadcast scope "because adoption will find the right users". It won't. Credits will find every user.
- No human-in-the-loop on an action-taking agent. Users will re-invoke until the output looks right, each attempt spending credits.
- Full-corpus scans on every call. Architect never asked whether the corpus could be narrowed at the query.
- No monitoring in the go-live plan. The customer finds out about consumption from the invoice, not the dashboard.
- No owner on the customer side. When usage spikes, nobody on the customer team knows who approved what.
- Architect can't name the value-per-credit story. If we can't articulate what each credit is buying, we're not ready to defend the bill.
What to do when you spot one
Raise it in the design review, in writing. Propose the cheaper pattern that delivers the same outcome. If the customer still wants the expensive path, document that they chose it with the forecast in front of them. A bill they've seen coming is a conversation; a bill they haven't is an escalation.
Worked example - reading the architecture
A customer asks: "Can we just swap the LLM behind this agent for a cheaper one to reduce credits?" Work through it the way an architect should.
1. Name what the agent actually is. It's a Workday-shipped agent running in the customer's tenant, priced in flex credits. The model and reasoning depth are part of what Workday ships - they're not customer-configurable knobs. That alone answers the literal question: no, we don't swap the model.
2. Re-read the real question. "Reduce credits" is the goal; "swap the LLM" is one guess at how. The architecture constraint rules the guess out, so redirect to the levers that are available.
3. Walk the four consumption variables. Category is fixed. Population, frequency and data volume per call are all architectural choices the customer controls. That's where the saving lives.
4. Offer the cheaper pattern. Narrow scope, move from real-time to event-driven, tighten the data passed per call. Same outcome, lighter credit footprint, no tenant-boundary compromise.
5. Close the loop. Document the forecast against the new scope, and set the soft and hard caps before go-live. The customer now has a lever they can see and turn - which is the point.
The pattern generalises: when a customer proposes a fix that sits outside what the architecture allows, name the constraint, then redirect to the levers that remain. That's the method this module is teaching.
Check your understanding
Four questions. Each explains why every answer is right or wrong - the reasoning matters more than the score.
Next steps
- Architects: Module 6 - Simplifying integrations with agents - integration patterns shape consumption too.
- Architects & commercial: Module 7 - Predicting credit consumption - the numbers side of this module.
- Senior architects: Module 11 - When to build - custom agents have their own credit profile; understand Use, Adapt, or Build before committing.
- EMs and commercial: read this module for awareness, then align with your architect on the credit-forecast conversation at design time.