The 9-Step Framework for Deploying Agentic AI in an Entrepreneurship College

Here is the part nobody says to the founder of an entrepreneurship college out loud. Somewhere between your first small cohort and a full intake calendar, you stopped being the teacher and became the operating system.

Every application, every offer with an expiry date on it, every "did that deposit ever land", every applicant sitting on a decision, every enrolled student who was never actually invoiced waits on your attention, which means the whole college fills exactly as fast as one founder can read.

This is the framework we use to take that job off the founder and give it to a system, without the risk that comes with letting software near an applicant's decision and a family's money. It is nine steps in three phases.

Four before you build anything, three to build it, and two to do the thing the whole exercise is for, which is to remove yourself from the middle of every application, every offer and every enrolment.

It is worth saying what this is not. It is not a new student information system, and it is not "let AI teach the course".

The teaching, the mentoring, the judgement about who is a fit for your programme, all of that stays with your people. What changes is that the reading, the sorting, the chasing, the filing and the drafting stop landing on one desk, so an offer never quietly expires because the founder was buried in enrolment paperwork the week it mattered.

You quietly became the operating system

It happens slowly. In the early years you ran the enquiries, the interviews, the offers and the onboarding yourself because there was nobody else, and you were good at it, so the college grew.

Then the intakes kept coming and the routing never left your head, because it was faster to just do it than to write it down. Now you are the one who notices an offer is about to expire, who remembers an applicant still owes their deposit, who spots that a student who started three weeks ago was never actually put on an invoice.

None of that is written down anywhere. It lives in your attention, and in an education business attention is the scarcest thing there is, because it is competing with the actual work of teaching and building the programme.

Three things follow, and every one of them costs the college real enrolments and real fees.

• The college fills at reading speed. A founder spending two or three hours a day reading enquiry emails, chasing deposits and checking who has accepted what is normal. That is not teaching and it is not selling the programme. It is triage, done by the one person the whole institution is named after.
• Offers get accepted because somebody chased them. Which is fine until the one busy week nobody did. An offer that expires unaccepted is not a neutral event, it is a student who was ready to say yes drifting to a competitor who answered faster, and a seat in the cohort that stays empty.
• Nothing survives your holiday. A college where the founder is the router does not keep filling when that founder is away. Applications sit unread, offers lapse, deposits go unchased, and you find out the size of the hole when you get back and the intake is half full.

The instinct is to fix this by hiring another admissions person. That works, and it also adds salary, supervision, and one more person who has to learn all the unwritten rules you were already the only keeper of.

You have not removed the bottleneck, you have given it a second head to depend on, and when that person leaves they take half the routing with them. The alternative is to write the routing down and let a system run the parts that never needed a founder's brain in the first place.

That is what the next nine steps do.

For an entrepreneurship college, the student experience is the marketing

One belief before the framework, because it decides how you read the rest of it. In an education business, the student experience is the marketing.

Not the brochure, not the logo, not the ad spend. The enquiry answered the same day, the offer that arrived warm and personal instead of two weeks late, the onboarding that made a nervous new student feel like they had made a good decision, the mentor who noticed when someone went quiet in module three.

That is what fills your next intake, because a college grows on referrals and reputation more than on any single campaign, and every one of those moments is produced by the nine jobs we are about to automate.

This is why it belongs on a growth marketing site rather than in an IT catalogue. An offer that expired unaccepted is not an admin slip, it is a paying student you already earned and then lost to your own slowness.

An applicant who went cold because nobody followed up is not a pipeline metric, it is churn before enrolment. And a cohort that felt ignored between the deposit and the first module is next year's empty seats, because they will not send you their friends.

When the operating system is one tired founder, the student experience frays in exactly the places a prospective student notices and a rival college points to.

Which brings up the trap most growing colleges fall into. They try to grow by driving more enquiries, more ad spend and more open days, into an admissions process that still runs through the founder.

That does not produce a fuller cohort. It produces more applicants going cold, more offers lapsing, and a founder who is now drowning in leads they cannot convert fast enough.

This is the capacity problem, and it is one of exactly three things almost every stuck education business is stuck on. The other two are getting the right applicants in and converting them, and I have written the full diagnostic in the 3A Machine.

So the goal of deploying agentic AI in a college is not "use AI to run the classroom". It is to build the admissions and onboarding capacity that lets you fill every intake without the experience falling over.

Get the nine steps running and the same founder and the same small team convert two or three times the applicants, onboard every one of them well, and lose none of them in the gap between yes and the first module. Fix capacity first, then go and drive the enquiries, because now they will actually turn into enrolled students.

The nine steps, in three phases

Here is the whole map on one page. Your college already runs all nine of these jobs today, whether or not anyone has ever named them.

The framework does not add work. It names the jobs, then decides one at a time whether a person does each one or a system does it.

Notice the shape. Four steps happen before anybody builds anything, and skipping them is the single most common reason a college's "let us try some AI" project quietly dies.

People buy the clever part first, point it at nothing in particular, and end up with a fast chatbot on the website that does not know how admissions actually runs. The order below is designed to stop that.

Step 1. Diagnose: find what is actually bleeding

You cannot fix what you have not counted, and most colleges have never counted this. So the first step is a leak audit, and its only job is to put a number on the enrolments and the fees already walking out of the building.

Not a survey of how everyone feels about admissions. A count of losses.

In an education business the leaks are always in the same few places. Offers that were sent and then expired unaccepted, because the personal follow-up that would have closed them never went out in time.

Applicants who enquired, got one reply, and then went cold in the silence because nobody owned the chase. Deposits that were requested and never chased, so the place was held for weeks against money that never arrived.

And the quietest leak of all, students who were actually enrolled and started the programme but were never put on an invoice, or whose payment plan quietly slipped a month and nobody noticed. In most colleges this last one is genuinely uncomfortable the first time it is counted, because the seat was filled, the teaching was delivered, and the fee simply never got raised.

Add it up honestly and the total is almost always bigger than expected, and concentrated in two or three places rather than spread evenly. That concentration is the gift.

It tells you exactly where to point the build first, whether that is the offers going cold or the fees never invoiced, and it becomes the before number you use, at the very end, to prove the system paid for itself.

Step 2. Shadow: follow one real applicant from application to enrolment

Now you watch. Pick one live applicant, someone who has just enquired about the next intake, and follow them end to end, from the first form to the day they are enrolled and onboarded, writing down every single thing that happens and every decision anybody makes.

Not the tidy version in the admissions handbook nobody opens. The real one.

This is where you discover the college does not run on the written process. It runs on a hundred unwritten rules that live in your admissions lead's head and, more than anywhere else, in the email threads and the WhatsApp chats.

How long an offer really stays open before you quietly extend it. Which applicants you always call personally rather than emailing.

The point at which a deposit request goes out, and how many times you chase it before you release the place. The kind of applicant you never enrol without a conversation first, because they are not ready and they will drop out in module two.

None of it is written down, all of it is load-bearing.

The excavation is the real work of this step. You read back through the threads and pull out the rules the college actually operates on, the ones that were never a decision, just a habit that turned out to be right.

That messy, lived-in reality is what you are about to encode. Skip it and you will automate the fantasy version of admissions, ship it, and watch your team quietly go back to running offers their own way because the system does not know what they know.

And be honest about the fragility this surfaces: in most colleges the real admissions manual is one long-serving person's memory, and it walks out of the door the day they leave for a competitor.

Step 3. SOP: write the unwritten procedure down

Everything you excavated now becomes one written procedure. Plain language, step by step, in the order it really happens, with every rule and every exception stated.

This is the least glamorous step in the framework and it is the one that makes an agentic system possible, because an admissions controller can only work a procedure that has actually been written.

The heart of it is an enrolment checklist, and it is worth writing as a hard gate rather than a gentle reminder. A student is not enrolled until six things are true: the application is in, the offer has been formally accepted, the enrolment agreement is signed, identity and any required proof are on file, a deposit or an agreed payment plan is in place, and onboarding is scheduled.

Written as a procedure, that becomes a gate a machine can enforce perfectly, every time, so nobody is ever quietly marked enrolled on a busy intake day with a signature or a deposit still missing. The same discipline applies to sending an offer, chasing a deposit, and running the onboarding sequence.

Each becomes a written sequence rather than a thing your admissions lead simply "knows".

Write it for a smart new hire on their first day, not for a machine. If a person could follow it without asking a single question, a system can run it.

If it still needs somebody to "just know" when to extend an offer or waive a deposit, the procedure is not finished, and you are not ready to build.

Step 4. Baseline: agree the numbers before you touch anything

The last step before the build, and it is thirty minutes that saves you a year of arguments. Write down the current numbers and get the founder and the admissions lead to agree them.

How long it takes to file a signed form to the right student record today. What share of offers actually get accepted before they expire.

How much in fees is sitting enrolled but not invoiced right now. How fast the first reply to a new enquiry goes out.

Real numbers, honestly rounded, on the record.

You do this for one reason. In three months, when the system is running, memory rewrites history.

People forget how leaky it was, decide admissions was "always basically fine", and start to wonder what they are paying for. The baseline is the receipt.

It is what lets the weekly proof report at the end say "filing a form went from about twenty minutes by hand to about two" and have that land as a fact everyone agreed up front, rather than a vendor's claim.

It is also the moment to decide what "better" means for this college, so the build aims at a number and not a vibe. A college bleeding on offers that expire unaccepted is not chasing the same win as one drowning in enrolled students who were never invoiced.

Name the number now. It is what everything you build next is pointed at.

Step 5. The command center: the whole college on one screen

Now you build, and the first thing you build is the place the founder looks. One screen that shows the whole college at a glance, in the order that costs enrolments, so nobody reconstructs the state of the intake from six systems and a group chat every morning.

Build it on one spine, not twelve tools. This matters more than it sounds.

Every job in the audit is tempting to solve with its own separate app, a form tool here, a payment link there, a spreadsheet for the cohort, a chat thread for the chasing, and a year later you have a dozen subscriptions that do not talk to each other and a founder who is now the integration layer between them. Build the whole thing on one foundation, one place the data and the context live, and the next piece is nearly free because everything it needs already exists.

The centre of the screen is a cohort radar: every applicant and student, ranked not by when they enquired but by who needs action first. The offer that is 48 hours from expiring unaccepted sits at the top, in red, whether or not anybody asked.

Around it, the numbers a founder actually needs, how many students need action today, how many offers are at risk of lapsing, how much in fees is delivered but never invoiced, and how many intakes are about to close.

Then the deadline clock. A college does not have one deadline, it has dozens running at once across every applicant and every intake, and a single shared inbox flattens them into a comforting average that hides the one about to lose you a student.

The command center pulls them apart and shows each on its own, so the offer acceptance window, the deposit due date and the enrolment close for the intake are three separate clocks, and the dangerous one is the one you see.

Beside the clock, the fees on the floor: every student enrolled, onboarded, sitting in a cohort, and never invoiced. In most colleges this is a genuinely uncomfortable number the first time it appears on a screen, because the seat is filled and the teaching is being delivered and the fee simply never got raised.

It was not a decision. It was that raising the invoice, or resuming a payment plan that had stalled, was a small annoying job nobody owned, which is a fair description of most of what leaks in a growing college.

And the document wall. An established college is sitting on an enormous pile of student records, applications, signed agreements, ID, payment plans, progress reports, across folders nobody has fully mapped in years.

The command center reads that existing storage where it already lives, with no migration and no "please move every student into our new system", and makes it navigable and countable, so any record is found in seconds instead of a frightened hunt while an applicant waits on the phone and their patience with your college quietly drains.

One design choice worth naming, because founders always ask. The command center is owner-locked, and the team gets read-only logins scoped to what they need.

The founder sees the fees and the whole board. An admissions officer sees the applicants and offers assigned to them.

A mentor sees the students in their cohort. Nobody can quietly change a number they should only be reading, and the founder never loses the single honest view of the college the whole build exists to give them.

Step 6. The procedure as data: the college's mind

The procedure you wrote in step 3 is a document, and a document just sits there. In step 6 you turn it into data the system can reason over: every rule, every deadline, every checklist, every onboarding playbook, and every good answer the admissions team has ever given, connected by meaning rather than filed in folders.

This is the college's mind, and it is what makes the admissions controller in the next step sound like your college instead of a generic model.

In practice it means anybody can ask a plain question and get the college's own answer, not the internet's. What do we need before we can enrol a student.

How long does an offer stay open for this programme, and what is our policy on extending it. What is the payment-plan structure we agreed for applicants who cannot pay the fee up front.

The answer comes back grounded in the college's own written procedure, with the source it came from, so it is checkable rather than a confident guess.

The reason this matters more than it looks is drift. A general model, asked the same admissions question twice, will happily give two confident and slightly different answers, and in an enrolment process that is not a quirk, it is a liability, because a wrong answer to an anxious applicant about deposits or deadlines can cost you the student.

Grounding every answer in the college's own written procedure kills it. The system is reading your rules and quoting them with the source, and when a rule changes, a new intake date or an updated payment plan, you change it in one place and every answer changes with it.

It is also where the enrolment checklist becomes enforceable rather than advisory, because the admissions controller in the next step reads its gate from exactly here: application, accepted offer, signed agreement, ID and proof, deposit or agreed payment plan, and onboarding scheduled, all six before anyone is marked enrolled.

Step 7. The admissions controller: chasing and filing that shows up on time

Now the part people picture when they hear "AI". An employee, not a chatbot, and the distinction is the whole thing.

A chatbot waits on the website to be asked. An employee wakes on a timer, reads the live intake, does its round, files the work, chases what is slipping and flags what needs a human, whether or not anybody prompted it.

I have written the longer version in AI employees, not chatbots.

In a college it is a small crew of them, each with one job, all reading from the college's mind. An admissions controller that reads a photographed or uploaded form, understands it, files it to the right student record, sets up the payment plan and schedules onboarding.

A refusal fence that will not let a student be marked enrolled until every item on the enrolment checklist is present. An invoice filler that drafts the fee for a place that has been filled, straight from the record of the enrolment.

A talking agent that answers an applicant's question about deadlines, deposits or the programme, in their own language, without pulling the founder off the work of actually running the college.

There is a quieter agent in this crew that founders never ask for and always end up valuing most: a critic. Before any piece of work reaches a human, a second agent grades it against the procedure.

Is the form filed to the right student, is the enrolment checklist actually complete, does the drafted invoice match the agreed fee. Anything that fails goes back to be redone before you ever see it.

This is the line between AI you can run and AI you can trust in a college where a wrongly enrolled student or a mis-stated fee is a real problem with a real family on the other end of it.

An employee that can act is useful and it is also dangerous, so this step ships with four safety rules and they are not optional. They are the reason you can hand a system this much and sleep.

• It refuses out-of-procedure work. If a form or a request does not match the written procedure, or if an enrolment is attempted with the checklist incomplete, the admissions controller declines and escalates rather than improvising. No student is enrolled until the enrolment checklist is complete. The refusal fence is a feature, not a failure.
• Every file operation stays inside set boundaries, and deletes go to a recycle bin. It cannot reach outside the student folders it was given, and nothing it removes is ever gone. A form filed to the wrong record is always recoverable.
• Every applicant-facing message waits for a human yes. It drafts the offer nudge, the deposit reminder, the welcome sequence, the invoice, then stops. A person reads it and presses send. Anything that touches an applicant, their money or the college's name gets a human on it.
• Ambiguous figures and dates come back empty, never guessed. If it is not sure which fee a payment belongs to, or when an offer actually expires, it says so and asks. A blank is safe. A confident wrong deadline sent to an applicant, or a wrong fee on an invoice, is how a system does real damage.

Step 8. Hand it to the team

The build is running. Now it stops being the founder's private tool and becomes how the admissions team works, and the shift is subtle but total: people move from performing the work to approving it.

The system does the first pass of everything, the offer nudge, the deposit chase, the enrolment filing, the invoice, and a person says yes, changes a line, or sends it back. Same team, far more applicants converted and onboarded well, and your people are left doing the human parts, the interview, the reassurance, the relationship, that were always the actual job.

That handover is made of a few specific things. A daily status drafter that writes the update an applicant is owed, ready for a person to approve.

An activity wall so the founder can see what the system and the team did without asking. A change watcher that notices when an applicant stalls at the same stage for days, or when an offer moves closer to expiry, or when a payment plan misses a date.

And the piece everyone feels first: the morning brief.

At eight in the morning, before anyone opens anything, one message lands in order of what costs enrolments: here are the two offers hours from expiring unaccepted, here are the intakes and payment plans that need action this month with the reminders already drafted, here is the delivered work waiting to be invoiced, here is the applicant stuck because their deposit never arrived. The team walks in already knowing the day instead of spending the first hour discovering it, and no offer expires simply because it was nobody's job to notice.

A word on the human side, because it decides whether any of this sticks. The word removal frightens a team, and if they think it means removing them, they will quietly starve the system of the knowledge it needs.

It does not mean that. It means removing the data entry, the deposit-chasing, the frightened record hunts, and leaving people with the applicant conversations and the student relationships that were always the enrolment-winning work.

Say it out loud, early and often. An admissions team that believes the system is on their side will feed it.

A team that fears it will fight it, and win.

Step 9. Removal is the whole point

Here is the step everyone gets wrong, and it is the reason the framework exists. Step 9 is not training.

It is removal. The goal was never to teach the founder to use a clever new tool.

It was to take the operating-system job out of the founder's head, so the college stops filling at the speed of one person's attention.

You know you have reached it by a specific test: the founder can take a genuine week off in the middle of an intake and nothing leaks. Applications still get read and filed.

Offers still get chased and accepted before they expire. Deposits still get requested and followed up.

Students still get enrolled the moment the checklist is complete, and invoiced the same day. Applicants still get answered in their own language, the same day.

Nothing waits for one person to come back and look, because that person is no longer the thing the routing runs through. They approve the exceptions from their phone, or they do not, and the intake still fills either way.

And this is where the baseline earns its keep. Every Monday a proof report goes to the founder and says, in the numbers everyone agreed at the start, what the system did this week.

Forms filed in minutes instead of the afternoon. Every offer chased before it expired.

Not one enrolled student left off an invoice while nobody was looking. It is not a dashboard somebody has to go and check.

It is the system reporting to the founder, unprompted, on whether it is still earning its keep.

And then the question that is really the point: what does the founder do with the attention they just got back. In every college the honest answer is the same, and it is why this belongs on a growth marketing site.

They go and do the work only the founder can do. Building the programme, teaching the parts that only they can teach, winning the partnerships and the placements that make the outcomes real, driving the enquiries that now actually convert because admissions no longer leaks.

Removal is not the end of the founder's involvement. It is the first time the founder gets to actually be the head of the college rather than its busiest admissions clerk.

What it costs to run

This is the question every founder asks within about ninety seconds, and the honest answer surprises people in the right direction. It is far less than they expect, and far more transparent, because the running cost is metered and shown like a utility bill rather than hidden inside a flat fee.

For a working system on a real college's volume, the AI usage runs on the order of a few dollars a day, and the hosting and database are a few tens of dollars a month, so the whole thing comes to roughly a hundred dollars a month to run. Your volume will differ, which is exactly why the meter is built in from day one and shown to the founder on day one.

No hidden meter, ever.

Now put that next to what it replaces, with round numbers you can redo with your own. Say the founder and the admissions team lose two and a half hours a day to chasing offers and deposits, filing forms by hand and answering the same applicant questions, across twenty two working days.

That is fifty five hours a month. Value that time at even a modest fifty dollars an hour, low for a founder's time, and it is over two and a half thousand dollars a month of attention, against roughly a hundred to run the system that gives most of it back.

And that ignores the two biggest wins, because neither shows up as time saved: the offer that stopped expiring unaccepted, and the enrolled student who finally got invoiced. Those show up as fee revenue that did not leave.

Where to start on Monday

Nobody builds all nine steps at once, and you should not try. This is a map, not a project plan, and the map is useful the moment you have it, because it tells you where you are and what the next single step is.

So do not start with the screen that impressed you most. Start with the step the audit said is bleeding worst.

If enrolled students keep slipping through uninvoiced, the fees-on-the-floor wall and the invoice filler pay for the whole build in the first month. If offers keep expiring unaccepted, start with the cohort radar and the deadline clock so no offer ever ages out unseen.

If your team is drowning in filing forms and chasing deposits, start with the admissions controller. The full logic for choosing the first thing is in what to automate first in a service business, and the honest way to measure whether it worked is in true ROI versus reported ROAS.

One thing at a time. Diagnose, build the one piece that hurts most, put a human gate on anything irreversible, then the next piece, which will be cheaper than the first because it sits on the same spine.

That is the whole method. This same framework runs in an accounting firm, a law practice, a clinic and a construction consultancy, the labels on the screens change and the nine jobs do not, and the full walk-through of the general version is in the 9-step framework for deploying agentic AI.

The colleges that end up with a real system instead of a browser full of half-used tools all started the same way: one step too small to fail, aimed at a number they had already agreed was bleeding.