For a long time, the word stack belonged to software developers.
If you were building applications in the early web era, you might have worked with LAMP: Linux, Apache, MySQL and PHP. Later came stacks such as MEAN and MERN, bundling together the technologies developers commonly needed to build modern web applications.
The names were useful because they compressed complexity.
Instead of describing every technology in an application architecture, you could say, “We use MERN,” and another developer immediately understood a large part of the environment.
The acronym became shorthand for capability.
Eventually, it became shorthand for people too.
Companies did not just build MERN applications. They hired MERN developers.
People learned the stack. Courses taught the stack. Recruiters searched for the stack. Developers put it on their resumes. An architecture choice gradually became part of professional identity.
Something similar needs to happen again.
But this time, the stack cannot belong only to developers.
Because AI is not changing only software development.
It is changing work.
The stack has escaped the technology department
Think about what has happened over the last few years.
A marketer can now research a market, analyze competitors, generate campaign concepts, produce images, write variations, build landing-page copy and monitor performance with the help of AI.
A lawyer can search documents, compare clauses, summarize cases, examine inconsistencies and draft arguments.
An accountant can classify transactions, investigate anomalies, prepare reconciliations, analyze financial statements and model scenarios.
A recruiter can research candidates, interpret job requirements, prepare interviews, analyze feedback and coordinate outreach.
A scientist can explore literature, process data, generate hypotheses, write code and challenge conclusions.
An executive can ask an AI system to examine a business problem, investigate the market, model alternatives and prepare a recommendation before the first human meeting even begins.
These people are not becoming software developers.
Yet each of them is beginning to assemble something remarkably similar to a technology stack around their work.
They have information sources.
They have models.
They have agents.
They have tools.
They have workflows.
And eventually, if the work matters, they need some way of establishing that the result can be trusted.
The stack has moved from the application architecture into the work itself.
That changes who needs to understand it.
LAMP organized software
LAMP was powerful partly because it gave web developers a common architecture.
Linux provided the operating environment. Apache served the application. MySQL handled the data. PHP, or another supported scripting language, provided the application logic.
You could swap pieces. You could argue about which piece was better. Technologies evolved around it.
But the deeper value of the idea was that developers could think in layers.
The application required different kinds of capability, and those capabilities could be assembled into a working whole.
MEAN and MERN continued that tradition for a different generation of web development.
MongoDB handled data. Express and Node.js served the application layer. Angular or React handled the user experience.
Again, the value was not merely the acronym.
It was the mental model.
A developer understood that building something useful meant bringing several distinct capabilities together.
AI-era work increasingly has the same shape.
Only now, the thing being assembled is not merely an application.
It is human and machine capability around an outcome.
The AI conversation started in the wrong place
Much of the early AI skills conversation focused on prompting.
That was understandable.
For millions of people, the first experience of generative AI was an empty text box.
You typed something.
The machine responded.
Naturally, we began teaching people how to type better things into the box.
Prompt engineering became a skill. Prompt libraries appeared. Courses promised hundreds of prompts for every profession imaginable.
Some of that was useful.
But it was always going to be temporary as the center of the AI skills conversation.
The better models become at understanding intent, the less professional advantage will come from knowing the cleverest phrase to put into a prompt.
The difficult part moves elsewhere.
Did the AI have the right information?
Should this work have been given to an agent rather than performed interactively?
Which model should handle the problem?
Should several models be involved?
What should remain human?
How do we know the answer is correct?
What happens when it is wrong?
Those questions cannot be solved by a better prompt.
They require a broader way of thinking about work.
From technology stack to capability stack
This is the idea behind RAMP.
RAMP stands for:
Retrieval. Agents. Models. Proof.
It is a framework for work in the AI era.
There is an important difference between RAMP and the technology stacks that came before it.
LAMP and MERN describe technologies.
RAMP describes capabilities.
That distinction is deliberate.
The technologies underneath AI are moving too quickly for a durable framework to depend on individual products.
Today's leading model may not be tomorrow's.
Today's agent framework may disappear.
The way organizations store and retrieve knowledge will continue to evolve.
Entire categories of AI software that seem important now may eventually become invisible infrastructure.
If we defined the new stack using product names, it could be obsolete before organizations finished teaching it.
So RAMP sits one level above the products.
The implementation can change.
The capabilities remain.
Retrieval: What does the work need to know?
The first layer is Retrieval.
AI systems can possess enormous general knowledge and still perform terribly when they lack the context surrounding a particular piece of work.
A salesperson preparing for a meeting does not merely need generic knowledge about selling.
They need to know the account.
What has the customer purchased? What conversations have already happened? Which problems remain unresolved? Who is involved? What changed recently? What does the customer care about?
A software engineer investigating an outage needs source code, logs, system architecture, deployment history and telemetry.
A lawyer reviewing a contract needs the contract itself, company policies, previous agreements, regulatory context and commercial objectives.
A supply-chain planner needs orders, inventory, routes, supplier performance, demand and operational constraints.
The AI model may be the same.
The context is what makes the work different.
Retrieval is therefore not simply the ability to search.
It is the professional ability to understand what information an outcome depends on, find that information, assess whether it is reliable and make the relevant context available to the intelligence doing the work.
That is why Retrieval belongs in the new capability stack.
Garbage in has always produced garbage out.
AI simply makes it possible to produce very polished garbage much faster.
Agents: What should do the work?
The second layer is Agents.
This is where the AI shift becomes more profound.
Software used to wait for us.
We clicked the button. We filled the form. We ran the report. We moved the information from one system to another.
Agents can increasingly perform sequences of work.
They can observe, decide, use tools, complete actions, check results and continue toward an objective.
That changes the relationship between a professional and technology.
A recruiter may eventually supervise agents that continuously identify candidates, research their backgrounds, personalize outreach and coordinate interviews.
A financial controller may have agents monitoring transactions and investigating exceptions before a human ever sees them.
A marketer may coordinate research, content, design, distribution and analytics agents around a campaign.
An engineer may delegate portions of coding, testing, documentation, security analysis and deployment preparation.
The important skill is not knowing how to click an “agent” button.
It is knowing what should be delegated.
What objective should the agent receive?
What systems should it be allowed to access?
What decisions can it make?
Where should it stop?
When does a human need to enter the loop?
What happens when several agents are working on different pieces of the same outcome?
Those are work-design questions.
And they are going to appear in almost every profession.
Models: What intelligence should we use?
The third layer is Models.
One of the habits we will eventually outgrow is speaking about “AI” as if it were a single intelligence.
Different models are good at different things.
Some reason deeply.
Some respond quickly.
Some work with images.
Some understand speech.
Some generate video.
Some specialize in code.
Some can run economically millions of times inside routine workflows.
Some are worth using only when the problem justifies the additional cost and computation.
There will also be many situations where AI should not be used at all.
A simple deterministic rule may be safer.
Traditional software may be faster.
A human decision may be essential.
RAMP therefore does not assume that the answer to every problem is “use more AI.”
It asks a more mature question.
What intelligence belongs here?
That question will increasingly be answered by people who have never called themselves technologists.
A CFO will make model decisions.
A lawyer will make model decisions.
A marketing leader will make model decisions.
A doctor will make model decisions.
An operations manager will make model decisions.
They may not configure the model themselves, just as a CEO does not configure the company's database.
But they will need enough understanding to judge what kind of intelligence should participate in consequential work.
Proof: How do we know it is right?
And then comes Proof.
This may be the layer that defines the next era of professional value.
AI has made production extraordinarily cheap.
It can produce a report before you finish your coffee.
It can generate hundreds of lines of code while you are reading an email.
It can create an impressive market analysis, a legal argument, a financial explanation or an operating plan in minutes.
The problem is that polished output and correct output are not the same thing.
AI is remarkably capable of producing something that looks complete.
That makes professional judgment more important.
Proof asks whether the outcome deserves to be trusted.
For software, proof may include automated tests, security checks, performance validation and human review.
For financial work, it might require reconciling data, checking assumptions and independently reproducing calculations.
For research, it might involve source validation, methodology, replication and peer scrutiny.
For marketing, proof may ultimately be market response.
For a legal opinion, the standard is different again.
There is no universal Proof mechanism because there is no universal definition of correctness.
That is exactly why domain expertise still matters.
AI can help generate the work.
AI can even help verify the work.
But somebody needs to understand what evidence counts.
This is where RAMP stops being a developer framework
Put those four capabilities together and something becomes clear.
A developer needs RAMP.
But so does an accountant.
So does a lawyer.
So does a recruiter.
So does an architect.
So does a researcher.
So does a salesperson.
So does a founder.
Their implementations will look completely different.
The framework does not.
Take a recruiter.
Retrieval means assembling the actual context surrounding a role and candidate rather than matching keywords.
Agents might research candidates, handle outreach or coordinate scheduling.
Models could help understand experience, generate questions or analyze patterns.
Proof means making sure the resulting recommendation is based on evidence rather than an attractive machine-generated narrative.
Now take a software engineer.
Retrieval means understanding the codebase, system architecture, dependencies, logs and documentation.
Agents may write, test, inspect and document code.
Models may differ depending on the problem.
Proof involves tests, security, reliability and engineering judgment.
Same framework.
Completely different profession.
That is the point.
Everyone gets a stack now
This is the shift I think we are still underestimating.
In the software era, developers assembled technology stacks to build applications.
In the AI era, professionals will increasingly assemble capability stacks to perform work.
Their stack may include several models.
Several agents.
Internal company knowledge.
External knowledge.
Software tools.
Data sources.
Human colleagues.
Automated verification.
And their own domain expertise.
A person's ability will no longer be measured only by what they can personally execute.
It will increasingly be measured by what they can orchestrate responsibly.
That changes the meaning of professional leverage.
A great marketer may not personally write every piece of content.
A great engineer may not personally write every function.
A great analyst may not personally perform every calculation.
A great manager may not personally assemble every presentation.
The important question becomes whether they can cause the right work to happen, at the right quality, with the right combination of human and machine capability.
That is a much larger idea than productivity.
Your domain expertise did not suddenly become worthless
There is a strange narrative around AI that suggests domain expertise is about to become irrelevant because models already know so much.
I think this gets the direction almost exactly backwards.
When everybody gains access to intelligence, knowing how to judge that intelligence becomes more valuable.
Imagine two people using the same powerful financial model.
One has spent fifteen years understanding finance.
The other has not.
Both may be able to produce a spreadsheet.
Both may be able to generate commentary.
Both may even present the results convincingly.
But only one of them may notice that an assumption makes no sense.
That difference is enormous.
The same will be true in engineering, law, science, medicine, sales, operations and almost every serious profession.
AI does not eliminate expertise.
It gives expertise leverage.
The professional advantage of the future may therefore look something like:
Domain expertise × RAMP capability.
Deep knowledge of a field, multiplied by the ability to retrieve context, orchestrate agents, select intelligence and prove outcomes.
That combination is much harder to replace than either one alone.
Why “AI literacy” is too small
Many organizations are currently trying to make their workforce “AI literate.”
That is a reasonable starting point.
People should understand what generative AI is. They should know basic risks. They should know how to use common tools responsibly.
But literacy is not capability.
Being internet-literate does not make someone a software engineer, digital marketer or e-commerce operator.
Being financially literate does not make someone a CFO.
Literacy means understanding the environment.
Capability means being able to produce outcomes within it.
RAMP is intended to describe the second.
A RAMP-ready professional should not merely understand what agents are.
They should know when agents belong in their work.
They should not merely know that models hallucinate.
They should know how to design appropriate Proof around an important outcome.
They should not merely understand retrieval-augmented generation as a concept.
They should recognize when missing context makes an AI-generated answer dangerous.
That is a different bar.
We should stop teaching everybody the same AI course
Once RAMP is viewed as a universal capability framework, another problem becomes obvious.
Most AI training is too generic.
The accountant, software developer, procurement specialist, marketer and CEO are often introduced to essentially the same AI curriculum.
Here is generative AI.
Here is prompting.
Here is how to summarize something.
Here is how to draft an email.
Here are some productivity tips.
Useful, perhaps.
Transformative, probably not.
The accountant does not need the same RAMP depth as the engineer.
Their Retrieval problems are different.
Their agents are different.
Their model choices are different.
Their standards of Proof are different.
Even two accountants may need different paths depending on their work and existing capability.
The framework can be universal.
The learning should not be.
That may become one of the defining characteristics of AI-era professional development: standardize the capabilities, personalize the path.
RAMP should survive today's AI companies
There is another reason for defining the framework at this level.
The AI industry is moving too quickly to build a durable professional identity around individual products.
A course that teaches someone how to use ten fashionable AI tools may be useful this month.
That does not make it a career framework.
RAMP should survive model generations.
It should survive today's agent platforms.
It should survive today's retrieval architectures.
It should survive whatever interface replaces the chat window.
Ten years from now, Retrieval may work very differently.
Agents may be almost invisible.
Models may route themselves automatically.
Proof may be deeply embedded into systems.
The implementation of RAMP will change.
But the underlying questions remain remarkably durable.
What context does this work require?
What should be delegated?
What intelligence should participate?
How will we know the outcome is trustworthy?
Those are not product questions.
They are work questions.
The next full-stack professional
For years, “full-stack” meant something very specific in technology.
A full-stack developer could operate across multiple layers of an application rather than being confined to one narrow part of it.
Perhaps we are approaching a broader version of that idea.
Not everyone becomes a full-stack developer.
But more professionals become full-stack operators of intelligence.
They understand their domain.
They can find and structure context.
They can mobilize agents.
They can work across different forms of machine intelligence.
They can inspect and challenge outcomes.
They know where human judgment matters.
Most importantly, they remain accountable for what gets produced.
That is an extremely capable person.
And it has almost nothing to do with whether they can write JavaScript.
From LAMP to MERN to RAMP
LAMP gave developers a practical stack for an earlier web.
MEAN and MERN reflected another generation of application development.
Those stacks helped people understand what technologies belonged together.
RAMP begins from a different problem.
Artificial intelligence is pushing computing capability beyond the software team and into virtually every kind of knowledge work.
The lawyer now has a stack.
The marketer has a stack.
The accountant has a stack.
The scientist has a stack.
The salesperson has a stack.
The executive has a stack.
But their common stack cannot be a list of software products because the products will keep changing.
It needs to describe what they must be capable of doing.
Retrieval.
Get the right context.
Agents.
Delegate and orchestrate the work.
Models.
Apply the right intelligence.
Proof.
Establish that the outcome can be trusted.
That is RAMP.
The earlier stacks helped us build software.
This one is about learning how to work when intelligence itself has become part of the stack.
And this time, everyone is in it.