There is a phrase that has quietly become one of the most overloaded terms in the technology industry: prompt engineer.
It gets applied to everyone from the researchers at Anthropic or OpenAI who design the foundational behavior of large language models, to the marketing coordinator who learned to add “act as an expert” to the beginning of their ChatGPT queries. Both people are technically prompting an AI. The similarity ends there.
What nobody talks about — and what every SaaS and moving company buying an AI integration should understand before signing a contract — is the concept of prompt depth. The difference between being a first-level prompt engineer and a tenth-level removed one is not a minor technical distinction. It is the difference between building intelligence and renting the appearance of it.
The stack nobody shows you
When you use an AI-powered feature inside a third-party SaaS platform, you are not interacting with the AI. You are interacting with a long chain of instructions, guardrails, formatting rules, business logic filters, and safety wrappers — all of which were written by people you will never meet, for use cases that may or may not resemble yours.
Here is what that stack actually looks like, from the ground up:
- Foundation model training. A provider — Anthropic, OpenAI, Google — trains a base model on vast quantities of data and encodes fundamental behaviors through reinforcement learning from human feedback. The people working here are shaping the values, reasoning patterns, and limits of the model itself.
- System-level instruction layers. The provider applies constitutional AI guidelines, safety frameworks, and output formatting rules that govern how the model behaves across every interaction, everywhere in the world, for every customer simultaneously.
- System prompt design. A platform or API consumer writes a system prompt — the first layer most people think of when they hear “prompt engineering.” It sets the persona, the scope, the rules of engagement for that specific deployment.
- Retrieval-augmented generation. That company connects the model to their own data sources and knowledge bases so the AI can reason over real information rather than hallucinate answers.
- Business logic. Routing rules, escalation triggers, and output parsers extract structured data from the model’s responses and feed them into downstream systems.
- SaaS integration. A SaaS vendor wraps that application in their own UX, their own feature flags, their own rate limits.
- Vendor documentation. The SaaS vendor writes documentation telling their customers how to configure the AI features — itself a form of prompting, one step removed.
- IT configuration. The SaaS customer’s IT administrator configures the feature, making choices they may not fully understand about settings that directly affect model behavior.
- Power user customization. A power user at that company writes “custom prompts” inside the SaaS tool’s interface — the little text boxes that say “customize your AI assistant.”
- End user. Someone types a question into a chat box and presses enter, confident they are “using AI.”
Every single one of these people would be accurately described as working with AI. Only a few of them have any meaningful control over what it actually does.
When a software company announces that their platform is now “AI-powered,” what they are generally describing is entry at Level 6 or below. They have connected a third-party general-purpose AI to their existing product. They did not design the model’s behavior. They did not encode industry knowledge into its reasoning. They did not build accountability for its outputs into their architecture. They enabled an integration. That is a real capability. It is not the same thing as building an AI.
Any vendor can enable a toggle. Not every vendor builds the thing.
Being a first-level prompt engineer means you are not adapting someone else’s AI to your use case. You are building the use case into the AI from the ground up. You define what the model knows about your domain. You decide what it is allowed to do and what it must never do. You write the rules that govern how it reasons about a moving job, a storage claim, a government shipment, a corporate relocation — not as a post-hoc configuration, but as a foundational design decision baked into the architecture itself.
It also means you are responsible for what the AI does in a way that a Level 10 tenant never has to be. When something goes wrong at Level 10, there are nine layers of abstraction to point at. At Level 1, it is yours. That accountability is uncomfortable. It is also what professional-grade AI requires.
There are companies in this market that are five or ten years old. We respect the energy and ambition that comes with being new to a space — innovation benefits everyone. But there is something that only time can build, and no amount of venture capital, engineering talent, or third-party AI integration can accelerate: the knowledge that comes from being inside an industry through its cycles, its crises, its regulatory shifts, and its quiet daily complexity for over two decades.
The twenty years was never just about the software. It was about understanding why a linehaul rate dispute happens at 3pm on a Friday before a long weekend, and what a dispatcher actually needs to see to resolve it in two minutes instead of two days. It was about learning — through thousands of deployments and millions of transactions — what this industry does, how it breaks, and what it needs to be better. It was about earning the trust of the operators, the agents, the coordinators, and the executives who run these businesses, and understanding their problems well enough to anticipate them before they ask.
That is not a five-year education. And it is not something you can integrate into your product from a third-party API. It either lives in the team that built your AI — or it doesn’t show up in the product at all.
I want to say something here that I mean with full sincerity: I am extraordinarily proud of our EDC® R&D team and what they have built with MERCED™. They did not take the easy path of enabling a toggle and calling it an AI product. They made the harder choice — to build something that is truly ours, truly purposeful, and truly accountable to the customers who trust us with their most sensitive data. What they have accomplished was made possible only because of the two-plus decades of domain knowledge they had to build on.
The demo looks the same. The difference shows up in production.
This is the truth that every AI vendor pitch obscures — intentionally or not.
In a demo, a Copilot or OpenAI integration and a purpose-built industry AI will appear functionally similar. Both answer questions. Both generate summaries. Both look impressive in a conference room. The evaluation committee nods. The slide deck says “AI-powered.” The box gets checked.
What the demo does not show: what happens when the AI is asked a question that sits at the edge of FMCSA compliance. How the AI reasons about the difference between a binding and non-binding estimate, and whether its answer exposes the company to a dispute. Whether the AI’s output reflects the actual workflows of the people using it — or a generic approximation of what logistics operations look like to someone who has never run one.
These are not edge cases. They are the daily reality of operating in this industry. And a general-purpose AI connected to a SaaS platform via API does not know the answers — because no one at Level 6 ever taught them to it.
Here is the practical consequence: organizations that deploy Level 10 AI features are fully responsible for outputs they have no visibility into. When a customer calls and says “your AI told me the wrong thing,” there is nothing to say — because the decision lived in a layer that was never accessible. The vendor will point to the integration provider. The integration provider will point to the model. The model does not take calls.
At MERCED™, when a customer asks why the AI made a particular recommendation, we can answer that question. Not because we are smarter — but because we built the thing. We know what it knows and how it reasons, because we designed those properties deliberately, informed by over 20 years of knowing this industry from the inside.
A practical question for every SaaS buyer
The next time a vendor tells you their platform is “AI-powered,” it is worth asking a simple question: At what level?
Are they a first-level builder who has designed AI behavior specifically for your industry, with full visibility and accountability for what it does? Or are they a tenth-level tenant who has enabled a toggle in a third-party API and called it a feature?
Ask them what happens when the AI gets something wrong. Ask them who owns that answer. Ask them how deeply their AI understands the difference between a military move and a commercial relocation, and who taught it. Ask them whether their AI was built on five years of product development or on twenty years of living inside this industry.
The demo will look the same. The answers to those questions will not.
We built MERCED™ at Level 1 because we believe this industry deserves that standard. Not the shortcut. Not the integration. The real thing — built by people who have spent over two decades earning the right to build it.
