From the Campus Operations edition of October 4, 2026
Andela case study: Nexford University's Claude-built Nex-OS spans enrollment, finance and assessment with defined human-judgment layers
Nexford University / Andela / Anthropic · Private online higher education / AI engineering services vendor · Global (online university)
- Publisher
- Andela Newsroom
- Original publication
- October 1, 2026
- Source retrieved
- 2026-10-05
What happened
Andela reports Nexford built Nex-OS, an AI operating layer over curriculum, assessment, enrollment, learner success, finance and internal operations, using the Claude API for workflows and Claude Code (with MCP servers across about 100 repositories and 31 centrally managed Skills) for engineering. Reported volumes: 525,424 enrollment contacts scored, 2,000 analyst hours saved on a taxonomy, 1,447 submissions graded, 425 curriculum gaps across 69 courses, and 14 departments using a shared decision log. Stated controls: finance AI is read-only, capstones stay faculty-graded, curriculum mappings need designer approval, and AI-supported decisions are logged.
Why it matters
Shows an AI-native institutional operating model where finance and enrollment operations share one agent platform and decision log; useful as a reference design for control layers, with limited transferability to large public campuses on legacy ERPs.
Evidence and measured results
Opened Andela's Oct. 1, 2026 case study listing tools, architecture, impact counts and the human-judgment layer for each product.
Limitations and uncertainty
Vendor case study with no baselines, accuracy measures, cost data or independent evaluation; counts are activity volumes, not outcomes. The 2,000-hour saving is a vendor estimate versus manual build. Nexford is a small online institution, so scale and governance transfer to traditional campuses is limited.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-04; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Institutions want AI across enrollment, finance and assessment without staff workload growing in proportion, but lack a control model for where humans approve decisions.
- Stakeholders
- Provost and academic leadership
- CFO / finance operations
- Enrollment management
- CIO and engineering lead
- Assessment and quality office
- Discovery questions
- Which operational workflows could run read-only analysis first?
- Where must a human approve before an AI output changes a record or grade?
- Do you have a central log of AI-supported decisions today?
- What engineering capacity exists to maintain agent integrations?
- Value hypothesis
- Interpretation: a shared agent platform with explicit approval layers could extend analysis coverage (e.g., full-population enrollment review) without proportional staff growth; no measured savings are established.
- Potential engagement
- A bounded control-design workshop mapping human-judgment layers and logging for two or three candidate workflows, followed by a read-only pilot plan.
- Unsupported claims
- No baseline, accuracy or cost data supports ROI claims.
- Grading quality and fairness are not evaluated.
- Transfer to large public campuses on legacy ERP is not shown.
Pre-sales engineering
Role takeaway
- Fit
- Institutions with API-accessible SIS/CRM/finance data and in-house or partner engineering able to maintain agent integrations.
- Architecture and integration
- Model API for workflow automation; agentic coding connected via MCP to repos, work items, pipelines and environments; centrally versioned Skills; a shared decision log and human work queue.
- Prerequisites
- API access to enrollment, finance and LMS data
- Central identity and secrets management for agents
- Decision-log and work-queue system
- Code review and change control for agent-authored commits
- Constraints
- Student-record privacy rules (e.g., FERPA in the U.S.) on enrollment scoring
- Single-model-vendor dependency
- Legacy on-premises ERPs may lack needed APIs
- Security
- Scope MCP and API privileges per agent, keep finance agents read-only as Nexford reports, log every agent action, and review agent-authored code before deployment.
- Proof of value
- Measure reviewer override and error rates on AI-graded submissions against faculty grading
- Compare enrollment scoring against historical conversion outcomes
- Audit agent permissions across connected repositories
Delivery
Role takeaway
- Work
- Pilot one read-only analytics workflow on a shared agent platform with a defined human-approval layer and decision log, then expand by workflow.
- Dependencies
- Data owners in enrollment and finance
- Engineering partner or internal team
- Model vendor enterprise agreement
- Ownership
- A central AI operations owner, with each workflow's business office owning approvals and outcomes.
- Skills and adoption
- Staff move from manual analysis to reviewing AI outputs and work queues; engineers need practices for maintaining shared agent Skills.
- Governance checkpoints
- Approval-layer definition before each workflow goes live
- Privacy review before population-scale enrollment scoring
- Quarterly permission and log audit
- Acceptance criteria
- Proposed: 100% of AI-supported decisions logged with reviewer identity
- Proposed: reviewer override rate tracked and below an agreed threshold before expansion
- Proposed: no write access for finance agents
- Risks
- Over-broad agent privileges
- Unmeasured grading quality
- Vendor and partner lock-in
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Platform pattern: model API for operational workflows plus agentic coding with MCP into repos, pipelines and work items; centrally versioned Skills propagate engineering practices. Campuses would need comparable integration and change control over SIS/ERP data.
Governance
Who approves, reviews and stays accountable for outcomes?
A per-product human-judgment layer and a central decision log (WorQ) are the governance mechanism; the case study does not describe audit, bias testing or incident handling.
Security and privacy
What data, permissions and controls need testing?
MCP access across about 100 repositories and environments creates broad agent privileges; enrollment scoring over 525,424 contacts raises data-protection questions the source does not address.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Framed as letting operations scale without staff workload growing at the same rate; that implies future hiring avoidance rather than stated cuts. Staff roles shift to reviewing queues.
Procurement
What should contracts, pricing and exit terms secure?
Engagements combine a model vendor and an engineering-services partner; buyers should separate model licensing, integration services and ownership of the resulting platform code and Skills.
Operating model
Which teams own the service once it runs?
Positions AI as the institution's operating layer with a shared decision log across 14 departments, a model most campuses would approach incrementally.
Publication history
- 2026-10-04Campus Operations · Issue 274 resources
Stable resource ID: andela-nexford-nex-os-claude-ops-20261001