How Current works
Nine services, one of which is a language model. The gap arithmetic, the permission checks and the option scoring are deterministic and testable.
Most talent software starts after someone has already decided the answer is “hire.” Current starts one step earlier: it detects the capability gap, decides which combination of build, buy, borrow or automate is most likely to close it, then does the operational work until human judgment is actually required.
Architecture
Not one large model with access to HR data. Each layer is labeled by what it actually is.
- 1
Signal layer
DataWatches approved plans, roster changes and delivery commitments for movement.
Why it works this way
Signals are changes in records the company already maintains — a plan revision, a resignation, a budget approval. No signal originates from a model guess.
- Delivery plan revisions
- Offboarding events
- Headcount approvals
- Scope changes
- 2
Employee Graph + business context
DataThe joined view of people, roles, skills, positions, budgets and objectives.
Why it works this way
This is the part a point solution cannot replicate: capability supply and financial constraints resolve against the same graph, with permissions attached to every edge.
- Roster and reporting lines
- Delivered-work skill evidence
- Positions and budgets
- Objectives and commitments
- 3
Gap detector
Deterministic serviceCompares required capability against available capability over a window.
Why it works this way
Arithmetic, not inference. Required minus available, integrated across the delivery window. A gap either exists in the data or it does not.
- Demand vs supply in FTE
- In-window reductions
- Confidence from data completeness
- 4
Permission + policy engine
Deterministic serviceDecides what this user may see and what Current may do, before anything is modeled.
Why it works this way
Permissions are inherited from the existing system, not granted to the agent. A path Current is not authorized to change is excluded from recommendations even when it scores well.
- Inherited record access
- Spend thresholds
- Worker classification
- Protected-attribute exclusion
- 5
Option modeler
Deterministic serviceScores Build / Buy / Borrow / Automate combinations against the user’s constraints.
Why it works this way
A weighted scoring function over capacity ramps, cost, durability, reversibility and confidence. Deterministic and testable — the same constraints always produce the same plan.
- Capacity ramp integration
- Constraint feasibility
- Coordination penalty
- Ranked alternatives
- 6
Narrative + drafting
Model-assistedWrites the explanation, the development plan, the scope of work and the agenda.
Why it works this way
This is where a language model is genuinely useful: turning structured decisions into readable artifacts. It does not choose the plan and it does not rank people.
- Evidence narratives
- Statement of work drafts
- 1:1 agendas
- Approval packets
- 7
Human decision nodes
Human decisionNamed people sit inside the graph, not beside it. Their answers release exactly one chain each.
Why it works this way
Three kinds appear in this plan: authority (Finance owns spend above the threshold), consent (an employee accepts or declines an assignment), and judgment (a recruiter authorizes who is contacted and what is said). A node with a gate is never runnable on its own — the orchestrator has no path that reaches it without a recorded decision.
- Plan approval — VP Engineering
- Contingent spend — Finance BP
- Redeployment — manager offers, employee answers
- Outreach campaign — recruiting lead
- 8
Dependency-aware orchestrator
Deterministic serviceRuns approved actions across Build, Buy, Borrow and Automate tools concurrently, holding only the chain that is actually blocked.
Why it works this way
Every action declares what it depends on. Status is derived from that graph rather than stored, so a decision Finance owns holds the contract chain and reaches nothing else — the learning enrollment and the recruiting campaign carry on. Each node re-checks its permissions at execution time and records what it touched.
- Build: development plans, learning enrollment
- Buy: success profiles, sourcing, campaigns, scheduling
- Borrow: statements of work, approval routing
- Automate: blocked at the policy engine
- 9
Outcome monitor
Deterministic serviceRecomputes the forecast from what actually happened, and grades the difference.
Why it works this way
Every recorded decision and completed action moves the projection. Deviations are classified rather than merely reported: a contractor who starts four days late inside existing slack costs nothing, and an internal ramp running behind inside the delivery window costs real capacity. Only one of those is worth a person’s attention.
- Projected vs modeled residual gap
- Confirmed vs expected capacity
- Drift classification and tolerance
- Estimate corrections for the next plan
- 10
Replan
Deterministic serviceWhen drift crosses tolerance or a person says no, the modeler runs again.
Why it works this way
A decline is not an error state. It is an input: the option modeler re-runs against the alternate candidate, the reduced scope or the changed budget, and produces the next honest recommendation rather than insisting on the old one.
- Employee declines → re-model against the alternate
- Finance declines → reduced-scope cutover options
- Drift beyond tolerance → new recommendation
Trust model
Eight things every recommendation has to carry. Missing any one of them makes the rest unusable.
Evidence
Every claim names the record it came from and when it was read.
Permissions
Inherited from the user’s existing access. Current holds no standing grants of its own.
Policy
Checks run against drafted actions, and a failed check stops the action, not the log.
Confidence
Calibrated from data quality, with the consequence of being wrong stated next to it.
Human boundary
Consequential decisions are enforced by the policy engine, not requested of a model.
Reversibility
Every action declares whether it can be undone before it runs.
Audit
Actor, tool, records, checks, timestamp. The trace the user sees is the log.
Feedback
The loop closes on the outcome, and corrects the estimate rather than a person’s record.
What ships first
Broad vision, narrow wedge. The MVP is not the whole suite.
- Phase 1
See and plan
In this prototypeDetect the gap from approved inputs, model Build / Buy / Borrow / Automate, show the evidence, get a human decision. This is what the prototype builds.
- Phase 2
Execute one branch deeply
NextBuild + Buy end to end: internal development plans, learning enrollment, requisition and campaign preparation. Depth over breadth.
- Phase 3
Cross-suite expansion
Contractor and automation paths, survey-to-action, performance action plans, learning personalization.
- Phase 4
Outcome learning
Measure which interventions actually closed gaps, and correct the estimates that were wrong.
Responsible use
What an employment-decision product has to be able to survive.
Protected attributes — and known proxies for them — are excluded from adjacency scoring and from every ranking in the product. That exclusion is enforced at the feature layer, not by instructing a model to behave.
Performance ratings are deliberately not an input to internal adjacency. In most organizations rating data encodes tenure and team more strongly than capability, and using it to route opportunity compounds whatever bias already exists in the ratings.
Where historical outcomes do influence a recommendation, the recommendation is inspectable and a fairness review affordance sits next to it.
- Rejects or advances a candidate
- Ends someone’s employment
- Assigns a final performance rating
- Changes compensation
- Makes a promotion decision
- Infers a protected characteristic
It summarizes, models, drafts, prioritizes, and executes reversible administrative work after a named person authorizes it.