Most Los Angeles businesses do not need Django. Most Los Angeles businesses need WordPress, possibly with a few custom plugins, and that is genuinely the end of the story. WordPress runs 43% of the web for a reason. It is a mature, well-supported content management system that works for brochure sites, blogs, small e-commerce, and most kinds of professional services marketing presence.

But there is a real category of business problem where WordPress stops being the right tool, and trying to force it leads to fragile, slow, hard-to-maintain systems that are more expensive than the alternative would have been. Django is one of those alternatives. This article is the test we use to tell which category a project belongs to — and why getting it right on the first call saves clients tens of thousands of dollars.

What WordPress is genuinely good at

Let us start with the honest part: WordPress is excellent at content publishing. Pages, posts, media library, a familiar admin interface, a large ecosystem of plugins, and a sea of developers who know it. If your business problem is “we need a website where non-technical staff can edit pages and publish blog posts,” the answer is almost always WordPress.

It is also surprisingly good at structured content. With custom post types and custom fields, you can model “events,” “case studies,” “team members,” or “products” cleanly. Most of the small business problems that look like custom applications are actually content modeling exercises that WordPress handles well.

Where WordPress becomes the wrong tool

Five signals consistently push a project out of WordPress territory and into Django (or another web application framework — Django is just the one we use most).

1. The center of gravity is a transactional database, not content. If the heart of your application is a set of tables with relationships, queries, and business rules — orders, appointments, cases, students, members, inventory — and the website is the front door to that data, you are no longer building a website. You are building a web application. WordPress can be bent into doing this, but you are paying for the bending in performance, maintainability, and developer time.

2. The user experience involves real workflow, not just reading content. “Log in, file a request, watch its status change as it moves through three reviewers, get notified when it is approved or declined, see your history” is a workflow. WordPress can do this with enough custom plugins, but those plugins become the most expensive and brittle part of your stack. A Django application that models the workflow directly is dramatically simpler.

3. You need role-based access control beyond editor/contributor/subscriber. WordPress has user roles, but they were designed for editorial workflows. If your business problem involves “users can see their own data but not other users’ data, admins can see all data within their department, super-admins can see everything across departments, auditors can see read-only access to a specific subset” — you are reinventing user permissions on top of WordPress, and it will fight you the whole way.

4. There is real domain logic that needs to be tested. Billing calculations. Eligibility rules. Tax computations. Scheduling logic with constraints. Things that have to be right, that have edge cases, that change over time as the business changes. In Django, these live in plain Python functions that you can write tests for. In WordPress, they tend to live in scattered shortcodes, theme functions, and plugin hooks, and they tend to silently break the next time a plugin updates.

5. You are going to integrate deeply with other systems. A few API calls to Mailchimp and Stripe? WordPress handles that fine with off-the-shelf plugins. A two-way integration with a court filing system, a hospital EMR, a payment processor with reconciliation, and an internal accounting system, all talking to each other through a central application? That is a Django (or equivalent) job. You can technically wire all that into WordPress, but the maintenance burden compounds quickly.

The real-world examples

Here is how this decision plays out for the kinds of LA businesses we work with.

A law firm building a new public marketing site. WordPress, every time. The site is content — practice areas, attorney bios, blog. Editors are non-technical. Plugin ecosystem solves 90% of needs out of the box. Even if you want AI features layered on, you can do that without leaving WordPress.

The same law firm building a client portal for case status, document sharing, and secure messaging. Django, every time. The center of gravity is sensitive data with audit logs, granular permissions, and workflow. WordPress would be a bad fit for the same reasons that made it great for the marketing site.

A nonprofit running an annual public event with a content-heavy promotional site. WordPress, with custom post types for sessions, speakers, sponsors. Possibly headless WordPress for performance if traffic is high.

The same nonprofit running a year-round member portal with directory, dues, voting, and committee management. Django. Member portals are workflow applications wearing a website costume.

A consulting business with a marketing site and a blog. WordPress. Add AI assistants and content automation on top — still WordPress.

The same consulting business building an internal tool to manage 200 active client engagements with phase tracking, time entries, and partner sign-offs. Django. Or any number of off-the-shelf project management tools, honestly, if one fits.

The hybrid that actually works

The most common real-world pattern for growing LA businesses is hybrid: keep your marketing site on WordPress, where editors are happy and content publishing is fast, and run a separate Django application for the workflow piece, on a subdomain. So the marketing site is at yourbusiness.com on WordPress, and the client portal is at portal.yourbusiness.com on Django. They share branding, share authentication if needed, but they are two different applications with two different jobs.

This is genuinely the right answer for most growing businesses. WordPress is best at the things WordPress is good at. Django is best at the things Django is good at. Trying to force one tool to do both jobs is the most expensive form of “saving money.”

What about Next.js and React?

Worth a quick note. Next.js and React are frontend technologies — they handle what the user sees. They are not alternatives to WordPress or Django; they sit in front of either one. A typical modern setup is “WordPress as the CMS, Next.js as the frontend” (headless WordPress) or “Django as the backend, Next.js as the frontend” (Django + decoupled UI). When we talk about WordPress vs Django, we mean the backend question — where your data lives and where your business logic runs. Next.js is a separate decision about how the user-facing layer is rendered.

The cost asymmetry

Here is the practical bottom line. A custom Django application typically costs three to five times more to build than a WordPress site for a comparable scope, because you are writing more code from scratch and there are fewer off-the-shelf parts.

But: a WordPress site forced to do a Django application’s job costs five to ten times what either would have cost done right. The wrong choice compounds — every plugin makes the next plugin more brittle, every workaround creates two more workarounds, and at some point the system reaches the “we need to rebuild it” point.

Picking the right tool for the right problem on the first call is the single most valuable thing a technical partner can do for your business. The honest answer most of the time is WordPress. When it is not, an honest partner will tell you so before you spend a year and forty thousand dollars discovering it.

Customer service is the most tempting place to apply AI and the most dangerous one to do it carelessly. The same conversation that delights a customer at 11pm on a Sunday can become a privacy incident if the system is built without thinking. This article is for business owners who want the speed and availability benefits of AI customer service — and want to avoid the obvious traps.

To be clear about what this is not: it is not legal advice. We are not going to claim “fully HIPAA compliant” or “guaranteed to meet CCPA” — those statements would be irresponsible to make in a marketing article. What this is, is the practical engineering perspective on building customer service AI that respects the privacy expectations your customers already have.

The expectation, plainly stated

When someone reaches out to your business, they expect a few quiet things. They expect their question to be read by your team, or at most the kind of automated system that books appointments at the dentist. They expect their data to stay with you. They expect that if they say something sensitive — a medical concern, a legal worry, a financial detail — it does not end up training someone else’s product. And they expect to be able to talk to a human if the situation calls for it.

Most AI customer service systems are built without sitting with those expectations first. The technology is impressive, the privacy posture is an afterthought, and the result is a system that technically works and quietly violates trust.

Where the real risk lives

There are three privacy pressure points in any AI customer service system. Knowing them lets you build defensibly.

The training set. Did the AI learn from real customer conversations? If yes, were they anonymized? Where are those records now? A surprising number of small-business chatbots are trained, fine-tuned, or in continuous learning loops on actual customer messages. That is fine if it is documented and consented to. It is a problem if it is not.

The runtime data flow. Where does the customer’s question go when they hit send? In a typical hosted chatbot product, the text travels from the customer’s browser to the chatbot vendor’s servers, then to OpenAI or Anthropic or Google for the actual model response, then back. Each of those hops is a place where a data-handling decision was made — sometimes by you, sometimes by the vendor’s defaults. Knowing what those defaults are is the entire game.

The records. Where do the conversation transcripts live after the chat ends? In your CRM? In the chatbot vendor’s dashboard, with full content searchable by their staff? On a server in a jurisdiction you would not have chosen? “I don’t know” is the most expensive answer to this question.

The safe-by-default pattern

The pattern we use for clinics, law firms, and other privacy-sensitive Los Angeles businesses has four parts. None of it is exotic — it is just being deliberate about each pressure point.

1. Train only on public information. The AI’s “knowledge” is your website content, your published FAQ, your service descriptions, and the documents your team explicitly hands over. It does not learn from live customer conversations. If a customer mentions a medication or a case number, that information stays in the conversation log — it does not flow back into the model’s training. This alone solves a large fraction of the privacy concern.

2. Use API providers, not learning loops. For the actual response generation, we use commercial AI APIs (OpenAI, Anthropic, Google) with the no-training option turned on. This is a real setting in their enterprise terms — your prompts and responses are not used to train future models. Configuring it correctly takes about ten minutes and removes a major category of risk.

3. Strip what does not need to be there. If a customer pastes their social security number into a chat (people do this), the system should redact it before storing the transcript. If a customer shares medical information on what they think is a general-information chatbot, the system should flag the conversation for human review and not surface it in unsecured logs. Building these redaction and flagging rules upfront is much easier than retrofitting them after an incident.

4. Always offer the human. Every AI customer service surface should make it trivially easy to ask for a person. A clear “talk to a human” button. A phone number. An email address. The most expensive privacy mistakes happen when the AI is the only door and someone gets desperate trying to communicate a sensitive situation.

What customers should be able to do

This is the operational checklist we walk clients through. If your AI customer service can do all of these, you are in a defensible position:

• A customer can ask for a transcript of their conversation and get it.
• A customer can ask for their data to be deleted, and someone can actually do it within a reasonable window.
• A customer can speak to a human within one click and one business day.
• A customer can find your privacy policy from inside the chat in one click.
• Your staff can search through past conversations and respect access controls — not everyone on staff sees everything.

None of this is new. It is the same operational hygiene you would build into a paper-based customer service operation. The technology just makes the rules easier to break by accident.

The two architectures that work

There are two reliable architectures for privacy-aware AI customer service. The boring pattern, and the slightly less boring pattern.

The boring pattern: assistant on top of public content. The AI is scoped to answer questions from your public website, FAQ, and service descriptions. If the customer asks something outside that scope — for example, about a specific bill or a specific appointment — the assistant says so and routes to a human. Most businesses can ship this in three to four weeks and it solves 50 to 70% of inbound questions without ever touching private data.

The slightly less boring pattern: scoped customer assistant. The AI is logged into a specific customer’s account context — it can see that customer’s appointments, billing history, or case file (and only theirs) — and answer questions about them. This is more useful and more dangerous. It requires identity verification, careful scoping of what the AI can see, an audit log of every query, and a clear separation between the model context and the data store. We do build these. We are careful about which clients we build them for.

The pattern that does not work: the AI plugged directly into your full customer database with no scoping, no audit, no identity check, and a “we’ll figure out the privacy story later” plan. We have seen this proposed. We have not seen it survive contact with reality.

What this means for your business

For most Los Angeles small and mid-size businesses, the right starting point is the boring pattern — an assistant trained on your public information, with a clear hand-off to humans for anything sensitive. It is the fastest to deploy, the cheapest to maintain, and the easiest to defend if anyone ever asks how your AI works.

You can layer in more capability later, once you have evidence that customers actually want it and your operations can support it. Privacy-aware engineering is not about having less AI. It is about having the right AI, scoped to the right problem, with the right guardrails on day one.

Most articles about AI for small businesses are written for a hypothetical company that does not exist — one with a clean dataset, a software team, and a budget to experiment. Real Los Angeles small businesses look different. A two-attorney firm in Westwood. A dental office in Pasadena. A nonprofit in Boyle Heights. A boutique consulting practice in Culver City. None of them have a machine learning team. All of them have repetitive work that someone is doing by hand right now.

This article is for those businesses. What is actually worth automating with AI in 2026, what is not, and where the real return on a few thousand dollars of investment shows up.

Start with what hurts, not what is trendy

The first instinct, when AI tools are everywhere in the press, is to ask “where can we use AI?” That is the wrong question. The right question is the one any small business owner already asks themselves quietly on Friday afternoon: “where am I losing the most time to repetitive work that should not need a human?”

If you make that list — really make it, with numbers, on paper — you will find that the same five categories show up across most small businesses:

1. Answering the same customer questions over and over
2. Manually triaging incoming leads and email
3. Drafting routine content (newsletters, social posts, simple proposals)
4. Copying data between systems that should talk to each other
5. Producing reports nobody reads but everybody expects

Every one of those is solvable today with practical AI automation at the small-business price point. The trick is solving them in the right order.

Tier 1: The FAQ assistant

If your team spends more than an hour a day answering the same questions, this is the highest-return AI project you can do. Cost: $2,500 to $5,000 to set up, plus monthly support. Payback: usually within the first quarter for any business with regular inbound questions.

The shape is simple. You give the AI a curated set of your business’s documents — your website content, your FAQ page, your service descriptions, your hours and policies — and it answers questions from that material on your website and via email. When it does not know the answer, it does not guess. It says “let me have someone follow up” and hands off to a real person.

The business value is not just time saved. It is that the AI answers at 11pm on a Sunday when your competitors do not. Most consumer-facing small businesses find that 30 to 50% of their inbound questions arrive outside business hours.

Tier 2: Lead triage and routing

If you get more than ten inquiries a week and someone on your team manually decides who responds to which, this one is next. A lead triage system reads incoming emails or form submissions, categorizes them (new client vs existing, urgent vs routine, in-scope vs out-of-scope), pulls relevant context from your CRM, and either routes to the right person or drafts a first reply for review.

The key word is “for review.” For the first three to six months, you absolutely want a human approving each automated reply before it goes out. After that, you can let routine categories go automatic and keep edge cases under review.

Cost: $3,000 to $8,000 to build, depending on how many systems it touches. Most of that cost is the integration plumbing, not the AI itself.

Tier 3: Content drafting workflow

If your business publishes content regularly — blog posts, newsletters, case study write-ups, social posts — an AI drafting workflow is worth setting up. Not “ChatGPT writes our blog.” A real workflow: research → outline → draft → human edit → publish, with AI doing the first three steps and a human owning the last two.

This is where small businesses tend to misuse AI most. They generate the post in two minutes and publish it. The result reads like every other AI-generated post on the internet, ranks for nothing, and tells your audience that you do not take your own content seriously.

Done right, the workflow saves you 60 to 70% of the drafting time while keeping the content recognizably yours. It is the difference between an AI tool and an AI system.

Tier 4: Data plumbing between tools

Almost every small business has the same problem: information lives in three or four tools (calendar, CRM, email, billing) and someone is the human glue. AI is now genuinely useful for the small-scale data plumbing problem — read this email, decide what kind of update it is, find the matching record in the CRM, update it, send a notification.

This is not really “AI” in the dramatic sense. It is just that large language models are very good at the messy parts (parsing free-form text, classifying intent) that used to require a human. The boring middle of business operations is where the real return lives.

What is not worth doing yet

To be honest about it: most small businesses should skip these for now.

Voice cloning and AI phone agents. The technology works in narrow demos, but the production reliability is not there for a small business that cannot afford to lose customers when it misfires. Wait six to twelve months.

“AI strategy consulting” engagements. If someone wants to sell you a $20,000 “AI readiness assessment” before any code is written, you are paying for slides. Skip it. Pay an engineer to build one of the things in the list above and learn what AI is good and bad at from the actual work.

Replacing your customer service team. Even at the largest enterprises, the right model right now is AI handling the routine tier and people handling everything else. A small business with one or two customer-facing people gains nothing by trying to replace them — and risks a lot by trying.

The privacy question

For Los Angeles businesses in regulated or sensitive spaces — clinics, law firms, anyone touching financial information — the privacy question is real and worth getting right at the start. The good news: the safest version of AI automation is also the easiest to deploy. Train the AI only on your public information. Keep sensitive records out of any prompt that goes to a third-party model. Put a human in the loop for any output that touches a real client.

This is not just risk management. It is also better automation. AI systems that are scoped narrowly to public, low-risk information are easier to test, easier to monitor, and less likely to embarrass you.

What two weeks looks like

The shape of a real small-business AI project: a week to listen and scope, a week to build a private prototype, a week to test with synthetic and then live traffic, and then steady refinement once it is in front of real users. Most of our small business engagements fit in this rhythm. The technology is no longer the constraint. The constraint is finding the right problem in your own business — and not over-engineering the solution.

If you own a business in Los Angeles and your website runs on WordPress, you have probably been told at some point that you should “go headless.” Maybe by a developer, maybe by a vendor, maybe by a Medium article that made the architecture sound like the difference between a Ferrari and a sedan.

The truth is more boring and more useful: headless WordPress is the right answer for some businesses and overkill for others. This article explains the actual difference, when each one wins, and what it costs you to change your mind later.

Traditional WordPress, in plain language

In a traditional WordPress site, the same software does everything. Your editors log into yoursite.com/wp-admin, write a page, hit publish. WordPress saves it to a MySQL database. When a visitor lands on the page, WordPress reads from the database, runs your theme’s PHP templates, mixes in any plugins, and produces an HTML page on the fly.

This is what 43% of the web runs on. It works. It is well understood. It has a massive ecosystem of themes, plugins, and developers who know it. For a brochure site, a small business presence, or a content-heavy blog, traditional WordPress is the right choice and trying to over-engineer it is a waste of your money.

Headless WordPress, in plain language

In a headless setup, WordPress only handles the back of the house. Editors still log into wp-admin and write pages the way they always have. But the public website — the part visitors actually see — is a separate application built in a modern frontend framework like Next.js or Astro. That frontend pulls content from WordPress through the REST API (or GraphQL) and renders it however it wants, on its own server.

You still get WordPress for editing. You no longer get WordPress for rendering. The “head” — the public-facing presentation layer — is somewhere else.

What you actually gain

Three things tend to matter to real businesses:

Speed. A well-built Next.js or Astro frontend serves static HTML for most page loads. No PHP, no database query, no plugin chain. The first paint happens in a few hundred milliseconds rather than a few seconds. For a business with paid traffic, this is not a vanity metric — it directly affects bounce rates and ad conversion costs.

Design freedom. WordPress themes are powerful but they push you toward a certain shape. A custom frontend lets your designers do whatever they want — animations, complex layouts, micro-interactions — without fighting the theme system. If your brand is part of your competitive edge, this is significant.

Security surface reduction. The wp-admin URL can be moved to a subdomain that is not in any search engine’s index and only your team’s IPs can reach. The public site does not run PHP, does not load plugins, and is not a target for the usual WordPress exploit traffic.

What you actually give up

This is the part most articles skip.

Preview becomes harder. In traditional WordPress, an editor hits “preview” and immediately sees the page exactly as it will publish. In a headless setup, preview requires extra plumbing — usually a draft API endpoint and a preview build of the frontend. It works, but it is not free.

Most page-builder plugins stop working. Elementor, Divi, Beaver Builder — all of them generate HTML and CSS at render time, on the WordPress side. If your frontend is not rendering WordPress’s HTML, those builders are not building anything anyone will see. You will be writing real components in code, or using a CMS-side block editor with a custom frontend renderer.

Hosting gets more complex. Two servers instead of one: the WordPress backend somewhere (often shared hosting or a small VPS) and the Node-based frontend somewhere else (a VPS, Vercel, Netlify). Two environments to monitor. Two SSL certs. Two deploy pipelines. For a small team this is a real ongoing tax.

Some plugins become irrelevant. SEO plugins like Yoast still help in wp-admin, but a lot of what they do — generating meta tags, sitemaps, schema — has to be reimplemented or replaced on the frontend. The plugin marketplace assumption breaks.

The honest decision tree

For a Los Angeles business deciding between the two, here is the test we use:

• Less than 5,000 visitors a month, brochure site, small content needs: Traditional WordPress. Caching plugin, decent host, done. Going headless will cost you more than you save.
• You spend money on paid acquisition and care about conversion rates: Headless is worth a serious look. The page-load improvement alone often pays for the rebuild within a year.
• You have a complex content team using Yoast, ACF, and editorial workflows: Headless, but keep WordPress as the CMS. Your editors do not need to know anything changed. They keep working in wp-admin.
• You have heavy custom functionality (members area, e-commerce, complex forms): Almost always traditional WordPress with WooCommerce or a learning management plugin, unless you are large enough to staff a real engineering team.
• You are starting fresh and care about brand presentation: Headless from day one. Going from traditional to headless later is expensive; starting headless is not.

What about hybrid?

There is a third option people forget: keep your main site traditional, and put a separate headless application on a subdomain for specific high-traffic or high-design pages. The marketing site stays on WordPress. The product, the pricing page, or the lead-generation flow lives in Next.js. Editors do not have to learn anything new for the main site, and the conversion-critical pages get the speed boost.

This is what most pragmatic small businesses end up doing. It is also what we build most often.

What it costs to change your mind

The good news: WordPress is a stable target. Content created in WordPress today is portable across both architectures. If you start with traditional WordPress and decide a year from now that you want a headless frontend, you keep all your content and just add the frontend application. No migration. No data loss.

That asymmetry is why we usually tell smaller LA businesses to start traditional and add the headless layer when there is a specific reason — a slow conversion page, a paid traffic problem, a design ambition — that justifies the second piece of infrastructure.

The technology should follow the business problem, not the other way around.

Walk into most law firm websites in Los Angeles and you find the same thing: a polished header, a few practice-area pages, and a contact form that has not changed in a decade. Submit it, and somewhere inside the firm a paralegal eventually copy-pastes your information into Clio or Practice Panther, types up a screening summary, and emails an attorney to ask if the matter is even worth a consult.

That whole loop is now being quietly replaced by AI intake assistants. Not chatbots that say “How can I help you today?” and then route you to a human. Real intake systems that ask the right qualifying questions, run a conflict check against the firm’s matter database, summarize the conversation, and put a structured matter brief in front of the attorney before they ever pick up the phone.

What an AI intake assistant actually does

The phrase “AI chatbot” covers a lot of ground, and most of it is not what a law firm needs. A useful intake assistant for a personal injury, immigration, family law, or business litigation firm typically does five things:

1. Qualifies the matter. It asks the dynamic questions a senior intake specialist would ask — what happened, when, where, who is involved — and adjusts based on the answers. A motor vehicle accident gets different questions than a slip-and-fall.
2. Captures the structured facts. Dates, names, jurisdictions, insurance carriers, damages — the things your case management system needs as actual fields, not buried in a paragraph.
3. Runs a conflict check. Against your existing client and matter database, before any privileged information is exchanged.
4. Routes by practice area and urgency. A statute-of-limitations issue gets flagged. A general inquiry waits for the next available associate.
5. Hands off cleanly to a human. Either a calendared consult with the right attorney, or a polite “this is not something we handle, here is what to look for” decline with no time wasted on either side.

Why web forms lose

A static web form has one job — capture a contact — and one mode: ask everything at once. Every additional field reduces submission rates. Every required field tries to predict in advance what information matters for every matter type. So firms end up with either thin forms that generate junk leads, or long forms that scare off the qualified ones.

An AI intake conversation has the opposite shape. It asks a few questions, listens to the answer, and asks the next question based on what was said. It can be longer than a form because it does not feel like a form. And it surfaces issues — like a missed statute of limitations or a conflict — that a form would simply collect and pass along.

The objections that come up — and the honest answers

“Is this UPL? Are we letting AI give legal advice?” A well-built intake assistant explicitly does not give legal advice. It collects facts, qualifies the matter, and schedules. Its scripts are written by the firm and reviewed by an attorney. Every response either asks a question, summarizes what the user said, or hands off to a human. This is the same thing your intake specialist does — and intake specialists are not practicing law either.

“What about privilege?” The intake conversation happens before an attorney-client relationship is formed, so it is not privileged communication in the technical sense. That is true of your web form too. What matters is data handling: encrypted at rest, access controlled, retention policies clear, and the user told upfront that what they share is not yet privileged. Good intake systems disclose this in the first message.

“Will it hallucinate?” This is the right question to ask, and the answer is: not if it is built correctly. A practical intake assistant is not a freewheeling chat model. It is a constrained workflow with a small, controlled set of allowable responses, an explicit knowledge base of the firm’s services, and refusal patterns for anything outside scope. The model is one component, not the whole system.

“What about clients who hate talking to bots?” They can skip it. Every well-designed intake assistant includes a clear “talk to a human” option, ideally with an actual phone number. The intake assistant exists to make life easier, not to gatekeep.

What it looks like in practice for a Los Angeles firm

A mid-size family law firm in West LA replaces its contact form with an AI intake assistant. A potential client visits at 11pm on a Sunday with an urgent custody question. The assistant asks the qualifying questions — jurisdiction, current court orders, immediate safety concerns — captures the facts, flags the matter as urgent, and books a Monday morning intake call with the available attorney. The attorney walks into the office with a one-page brief on her desk, not a vague form to chase down.

That is the actual product. Not magic. Not replacing the lawyer. Just removing the slow, error-prone middle step.

Where to start

You do not need to rebuild your website to do this. The intake assistant lives on top of your existing site as a chat widget or a dedicated intake page. Most firms can have a private staging version running within three to four weeks: one week to scope the conversation flows, one to two to build, and a final week to test with synthetic matters before any real client sees it.

The piece that takes longest is not the technology. It is sitting down with your senior intake person — the one who has been screening matters for fifteen years — and writing down what they actually do. The AI just runs the playbook they have already perfected.