Principal Enterprise Architect

First Student is North America’s leading provider of student transportation, helping millions of students get to and from school safely each day. Our technology teams build and support the operational, safety, customer, and employee-facing systems behind that work, including our HALO platform. 

AI is an area of active investment for us. We are moving toward a world where we can build what we need quickly and safely, and this role exists to make sure that speed produces a coherent enterprise rather than a fragmented one. 

About the Role 

You own the architecture of First Student’s technology estate through its transition to an AI-native operating model — and you hold the call on what we build, what we buy, and what we do not build at all. 

That last one is the point. Agentic development is about to make building software cheap. Cheap building without architecture produces an outcome most enterprises have already lived through once: thousands of Access databases, data scattered, unsecured, and poorly structured, and five custom CRMs because five lines of business each wanted their own. AI lets that happen faster and with more polish, which makes it more dangerous, not less. Your job is to prevent that while still letting us build whatever we genuinely need, with ease. 

This is a binding-authority seat. Buy it, build it with agents, fold it into an existing product, or do not build it — your decision stands. There are no direct reports; the authority comes from the seat and from the quality of your reasoning, not from headcount. 

You are not starting from nothing. We have a draft set of architecture principles and standards, a current view of the value stream, a prototype AI-native SDLC, and an agent control plane and runtime already in early use. Central IT does the majority of AI development today, with small pockets emerging in the field. What is thin is the thinking on how the business can safely ideate with AI inside a container, and how good ideas move through a gate into real products. That is the widest gap between what exists and what we need, though it is a smaller share of the job than deciding what gets built at all and making the enterprise buildable AI-natively. 

Our default lean is to buy the commodity and build the differentiator. SaaS for what is not specific to student transportation; build where our operating model is the advantage — routing, driver, operations, safety. Holding that line against “we could just build it now” is a real part of the job. 

How You’ll Work 

You work AI-native. You will not ship much code, but you design with frontier models and agents daily — authoring skills, rules, harnesses, and agentic workflows, and prototyping when a prototype is the fastest way to prove a design. This is not background familiarity. You cannot design agent-consumable architecture, interfaces, or knowledge if you do not live in the tools. Your output is architecture and decisions: patterns, reference designs, ADRs, standards, evals, and calls that hold. 

Authority is the backstop, not the operating style. You set the pattern and keep the final call, but you earn agreement inside the design process rather than ruling on it afterward. Teams should want you in the room early, not dread the review at the end. 

You also own a class of question rather than a fixed list. As the organization goes AI-native, settled assumptions come loose: whether work management built for humans reading tickets survives contact with agentic delivery, where documentation has to live for agents to consume it natively, how systems and agents talk to each other, who owns which entity and where copies of data are allowed. Jira-or-no-Jira is only an example. These questions arrive continuously, and you are the person who resolves them. 

A typical week may include: 

• Making buy, build, fold-in, or do-not-build calls on real requests, and writing down the reasoning so the decision holds the next time the question is asked. 

• Designing the integration and data architecture so new products plug into the estate rather than wire themselves into it. 

• Building out the safe harbor for business ideation and the gate that decides what happens to what comes out of it. 

• Working alongside the agentic delivery pod on a hard design, then carrying the resulting pattern outward to the teams that follow. 

• Resolving an open AI-native question that nobody has an established answer for yet. 

• Shaping enterprise knowledge management with the Product team so that principles, standards, and product knowledge are usable by machines as well as people. 

• Getting ahead of a line of business that is about to stand up something the enterprise already has. 

Key Responsibilities 

Decide what gets built 

• Hold binding authority on buy, build with agents, fold into an existing product, or do not build — across the full enterprise estate. 

• Own the intake and decision process behind that authority: how requests surface, how they are assessed, and how quickly they get an answer. 

• Default to buying the commodity and building the differentiator, and hold that line as agentic delivery makes building look free. 

• Own build-versus-buy evaluation, technical trade-off analysis, and vendor and platform fit. 

• Kill redundancy before it exists. Preventing the fifth CRM is worth more than integrating it later. 

• Document decisions and their reasoning so calls are consistent, reviewable, and reusable rather than re-argued every quarter. 

Architect the enterprise estate for coherence 

• Serve as the enterprise-wide architectural authority across the full estate: custom digital products (payroll, driver, operations, routing, scheduling, and customer- and employee-facing applications), the SaaS and ERP portfolio, cloud, data, and integration. 

• Settle system-of-record ownership and the canonical data model — which entity lives where, who owns it, and where copies are allowed. This is the control that prevents the Access-database outcome at AI speed. 

• Design the enterprise integration layer as a reusable, self-service capability teams adopt rather than request: API-first contracts, an event backbone, service and tool discovery, and identity for non-human actors. 

• Set cloud architecture direction on AWS — reference architectures, landing zones, and provisioning patterns, including environments autonomous agents can operate in safely. 

• Make a portfolio of distinct products behave as a coherent whole, and surface where system and team boundaries need to move together. 

Stand up the safe harbor and the gate 

• Design a contained environment where business teams can ideate and prototype with AI safely — sanctioned tooling, data boundaries, and blast-radius limits that make experimentation low-risk by construction. 

• Define the gate: how an idea coming out of the harbor is assessed, what qualifies it to move forward, and what happens to it — carried forward by central IT into an existing digital product, stood up as a new one, or discarded as redundant. 

• Keep the boundary explicit. The harbor is for ideation, not production. A business builder does not drive a tool all the way to production; central IT carries good ideas forward. 

• Assist in the design of the citizen toolset itself, so what the business builds is legible to IT and usable as a requirements artifact rather than a mystery to reverse-engineer. 

• Make the harbor good enough that the field uses it instead of going around it. Containment that people resent does not contain anything. 

Make architecture and knowledge machine-usable 

• Ensure an enterprise ecosystem for knowledge management is designed, coherent, and adopted. The Product team may well own the capability itself; you own that it exists at enterprise scope, hangs together, and is genuinely machine-usable. 

• Provide the design and guidance for how knowledge lives in an AI world — structure, retrievability, ownership, and freshness — so agents and people consume it natively instead of hunting through documents nobody reads. 

• Structure architecture principles, standards, patterns, and decisions as consumable artifacts rather than shelfware, so teams and agents pull from them by default. 

• Shape AI-native work planning, prioritization, and completion tracking, including whether tooling built for human-read tickets still fits when agents are primary consumers of work. 

• Encode standards as reusable scaffolds, safe defaults, and automated checks, so the right way is the easy way and formal review is reserved for genuinely irreversible decisions. 

Set the pattern for agentic delivery 

• Define what the paved road must guarantee — the control-plane pattern, agent runtime patterns, guardrails, evals, supervision, and observability substrate that keep autonomous systems in bounds. The agentic delivery pod builds and operates it; you decide what it has to hold true. 

• Work inside the group design process as a contributor, not a downstream approver, while keeping the final call on the pattern. 

• Make sure the first pod’s choices become the reusable pattern for the pods and teams that follow, rather than a one-off that has to be re-derived. 

• Design team boundaries and interaction modes so the organization’s structure produces the loosely-coupled, fast-iterating architecture the strategy requires (inverse Conway). 

• Stay deliberately agile as the underlying tooling evolves. Pilot, prototype, and recommend where new capability should be adopted, including EV technology, IoT and on-vehicle systems, cloud-native patterns, and frontier AI. 

Build security and compliance in by construction 

• Partner closely with the Senior Director of Cybersecurity and their team, who own risk assessment, to encode security, privacy, and regulatory requirements as policy-as-code and safe defaults. 

• Make the obligations attached to student and driver data, including FERPA and applicable privacy laws, inherited by construction rather than enforced by review. 

• Extend that same treatment to the safe harbor and to autonomous agents, where dynamic access provisioning and business-built prototypes expand the surface that has to stay compliant. 

Required Qualifications 

Two bars, and both are hard. You need real enterprise architecture breadth — the ability to hold the whole estate in your head and see the second-order effects of a decision — and you need to work AI-native yourself. A strong traditional architect who has read about agents cannot design for them. An AI specialist who cannot hold the big picture will optimize one corner and fragment everything around it. We need both in the same person. 

• 8+ years in enterprise, platform, or application architecture roles, with demonstrated depth and breadth across multiple IT domains and production systems at enterprise scale. 

• Demonstrable, current, hands-on practice working AI-native with frontier models and agents — authoring skills, rules, harnesses, and agentic workflows, and using them as your actual method of designing and deciding. This is measured by what you are doing now, not by years. 

• Working understanding of AI architecture: agent orchestration and runtimes, control planes, inference gateways and model routing, knowledge bases and context (RAG, MCP), evals, guardrails, and AI/MLOps. 

• Proven portfolio-level judgment: build-versus-buy decisions you owned, technical trade-off analysis, and the ability to make a decision stick with a line of business that wanted the other answer. 

• Deep integration and data architecture experience — API-first contracts, event and data streaming, canonical models, system-of-record ownership, and integration between enterprise systems such as ERP, payroll and HR, and proprietary platforms. 

• Experience architecting and integrating large-scale custom software products, internal and customer-facing, and making a portfolio of distinct products operate as a coherent whole. 

• Solid cloud architecture experience, ideally AWS — reference architectures, landing zones, well-architected design, containers and serverless runtimes, and automated or dynamic provisioning. 

• Design and guidance experience in knowledge management for an AI world: how documentation, standards, and institutional knowledge are structured so machines can use them. 

• Hands-on background across a full agile SDLC — discovery, scoping (PRDs and ADRs), delivery, testing, deployment, and support — with enough full-stack and DevOps grounding to be credible with engineers. 

• Experience in enterprise environments with real security, governance, data-handling, and regulatory constraints. 

• Strong written and verbal communication, including explaining architectural direction and trade-offs to both technical and executive audiences. 

• Bachelor’s degree in Computer Science, Engineering, a related field, or equivalent practical experience. 

Preferred Qualifications 

• Familiarity with architecture frameworks (TOGAF, C4, Zachman, FEAF) as practical tools rather than as the job itself. TOGAF certification a plus. 

• AWS certification, for example Solutions Architect – Professional. 

• Experience governing citizen development or low-code platforms at enterprise scale, including intake, promotion, and sunset. 

• Experience consolidating or retiring redundant systems, and living with the organizational friction that comes with it. 

• Experience with docs-as-code, developer portals, knowledge graphs, or MCP servers as machine-facing knowledge surfaces. 

• Experience with policy-as-code (for example OPA) and compliance-by-construction in regulated environments. 

• Platform-first architecture depth: base platform and child applications, plus shared services such as auth and accounts, messaging and notifications, search, files and media, and localization. 

• Experience with EV technology, IoT, telematics, and on-bus or on-vehicle technology solutions. 

• Experience with transportation, logistics, routing, geospatial, or operations-focused software. 

• Experience applying AI in governed enterprise environments, including FERPA-relevant or similarly regulated data. 

What Success Looks Like 

At 6 months: Buy, build, fold-in, and do-not-build decisions are running through a working intake with you as the decision-maker, and the reasoning behind them is written down where it can be reused rather than re-argued. Direction is set on system-of-record ownership and on the integration fabric. The draft principles and standards have moved toward artifacts teams and agents actually consume, and the enterprise approach to machine-usable knowledge has a real design behind it. Central IT is designing and planning against patterns you defined, and the agentic delivery pod is building on them rather than inventing its own. A first version of the safe harbor is standing in a contained environment with a defined gate. 

At 12 months: Demand is visibly shaped. Real requests have been bought, built, folded into existing products, or stopped; no line of business has stood up a redundant system; and the portfolio is flatter than it would have been without this seat. Standards are consumable rather than shelfware and teams pull from them by default, and enterprise knowledge management is designed, coherent, and genuinely usable by machines at enterprise scope. Central IT plans, designs, builds, and supports AI-natively on the patterns you set, with AI-native work planning, prioritization, and completion tracking in early working use. The integration and data architecture is holding as new products plug into it rather than wire around it. Alongside all of that, the citizen builder capability has a strong articulated vision and an early working form: the field ideates inside the harbor, and central IT carries the good ideas forward. 

Working Style 

This role decides, and shows the work. You will make calls that disappoint someone, and the reasoning has to be good enough to survive being read back to you a year later. Say no clearly, say why, and offer the path you would take instead. 

Collaboration is the method; authority is the backstop. The goal is that teams bring you in early because you make their design better, not because a gate forces them to. Use the authority when you need it and notice if you are needing it often. 

Much of this ground is genuinely unsettled. The tooling, the practices, and the right answers are all moving. You will need to take a position with incomplete information, keep it revisable, and change it when the evidence changes without losing the thread of the overall strategy.