Use Pull-First Thinking to Scope AI Projects

This small distinction matters more in AI work than many teams expect.

A company does not usually start an AI project with an empty room. It starts with old dashboards, half-trusted spreadsheets, SaaS tools, internal portals, document repositories, fragile scripts, analytics definitions, cloud commitments, compliance rules, and people who have learned to survive the current process. When the organization decides to build an assistant, agent, automation workflow, or data product, the natural instinct is to push all of that existing material forward.

That instinct is understandable. Existing assets feel cheaper than new thinking. Existing data feels like a head start. Existing software feels like something the team should preserve. Existing habits feel like requirements because people have lived inside them for years.

But an AI project can become expensive when it carries too much of the past into the future.

The better habit is to start with the work the organization actually wants to make possible, then pull in only what the future workflow needs. That does not mean ignoring the current environment. It means refusing to let the current environment define the solution too early.

For technical leaders, product managers, data teams, and AI builders, this is a practical scoping discipline. Before asking which model, vector database, agent framework, vendor, dashboard, or integration should be used, ask what deserves to be part of the next version of the work.

Start With The Workflow You Want To Keep

The first scoping question should not be, “Can we add AI to this process?”

It should be, “Which parts of this process are worth preserving?”

That sounds simple, but it changes the conversation. Many AI initiatives begin as a modernization layer over a process nobody has questioned for years. A support team wants an AI assistant because finding answers is slow. A finance team wants automated commentary because monthly reporting is painful. A data team wants natural-language analytics because executives dislike dashboards. An operations team wants an agent because handoffs take too long.

Each request may be valid. But the request is not the same as the need.

The support team may not need an assistant over every document. It may need a cleaner knowledge base, better ownership for policy changes, retrieval with citations, and clear escalation rules for sensitive cases. The finance team may not need generated commentary on every metric. It may need agreed thresholds for what deserves explanation, consistent metric definitions, and approval steps before commentary reaches executives. The data team may not need a chat interface over every warehouse table. It may need a semantic layer, access control, query limits, and a smaller set of trusted questions.

Inventory-first scoping asks, “How do we use what we already have?”

Pull-first scoping asks, “What must be true for the future workflow to work?”

That second question is harder, but it prevents a common failure: building a polished AI feature that faithfully reproduces a weak process.

This connects closely to the idea that AI requirements need to be understood before teams build. Requirements are not only a list of features. They are decisions about what the system should help users do, what it should refuse to do, what it must explain, and what still requires human judgment.

The Old Stack Should Reapply For Its Job

One useful way to run an AI discovery session is to make every asset reapply for its place in the future workflow.

Not politically. Practically.

The existing dashboard should justify its role. The spreadsheet should justify its role. The document repository should justify its role. The approval step should justify its role. The model choice should justify its role. The integration should justify its role. Even the familiar metric should justify its role.

This is not a call to throw away working systems. Mature teams know that replacement has a cost. But keeping something only because it already exists is not discipline. It is inertia.

A pull-first review might ask:

• What decision will this asset support in the future workflow?
• Who will depend on it, and under what conditions?
• Is the data accurate enough for the action the AI system may influence?
• Does this tool create traceability, or does it hide work?
• Does this approval step reduce risk, or only preserve an old habit?
• Does this model or vendor match the task, or is it simply the one the team already knows?
• What would break if we removed this item from the scope?

Those questions help teams separate useful history from accidental baggage.

AI makes this especially important because it can make old mess look modern. A language model can summarize inconsistent documents. An agent can move through a workflow with unclear ownership. A dashboard assistant can explain metrics whose definitions were never aligned. A coding assistant can accelerate changes to a brittle codebase.

The interface improves before the operating model improves.

That is dangerous. If the old stack contains weak definitions, stale knowledge, broken permissions, manual reconciliation, and unclear accountability, the AI layer may only make the weakness faster and harder to see.

AI Work Is Becoming Too Complex For Casual Carryover

Current AI engineering trends make pull-first scoping more than a tidy planning idea.

Google Cloud’s 2025 DORA report on AI-assisted software development frames successful AI adoption as a systems problem rather than a tools problem. That is the right lens. A coding assistant, internal agent, RAG application, or document automation tool affects the surrounding system: priorities, reviews, testing, value streams, feedback, and team habits.

Datadog’s State of AI Engineering shows the production side of the same trend. Teams are not only sending prompts to one model. They are managing model fleets, orchestration frameworks, tool calls, long prompts, retries, capacity, cost, observability, and service boundaries. More than 70 percent of organizations in Datadog’s customer telemetry use three or more models, which means model choice is increasingly a portfolio decision, not a one-time preference.

LangChain’s 2026 State of Agent Engineering points in the same direction for agents. Many surveyed teams now have agents in production, but quality, observability, and evaluation remain central concerns. The market has moved past the question of whether teams can build demos. The harder question is whether the workflow can be trusted, measured, and operated.

This is why casual carryover is risky. Every extra model, tool, data source, workflow branch, and approval path becomes something the team may need to evaluate, monitor, secure, document, and support. The cost is not only the implementation effort. It is the ongoing cognitive load.

Pull-first scoping reduces that load by asking what the system truly needs before the team imports everything available.

For example, a customer-support agent may not need access to every internal system on day one. It may need only policy retrieval, customer status lookup, and an escalation handoff. A data assistant may not need to query the whole warehouse. It may need a governed set of certified metrics. A workflow agent may not need broad write access. It may need to draft a recommendation, attach evidence, and wait for approval.

Scope is not only about project size. Scope is also about operational responsibility.

Use A Need-First Decision Table

Here is a practical artifact teams can use before committing to an AI implementation.

This table does two things.

First, it moves the conversation from assets to needs. Instead of asking, “Should we connect the agent to the CRM?” the team asks, “What future action requires CRM access, what permission should the agent have, and what evidence will prove the access is working safely?”

Second, it creates a place to say “not yet” without sounding anti-innovation. Some items may belong later. They simply do not belong in the first useful version.

That distinction is important. Good scoping is not small thinking. It is choosing a narrow enough version of the future workflow that the team can learn honestly.

Pull-First Does Not Mean Starting From Scratch

There is a bad version of this idea where every new AI project becomes an excuse to redesign everything. That is not practical.

Most organizations cannot pause operations while a team invents a perfect future state. They have customers, employees, budgets, compliance requirements, legacy systems, and deadlines. The current stack matters because the business is already running on it.

Pull-first thinking does not deny that reality. It simply changes the order of judgment.

Instead of beginning with everything already in the organization and trying to filter it down, begin with the target workflow and test each current asset against it. Some assets will clearly belong. Some will need cleanup. Some will need to stay outside the AI system until ownership improves. Some will be useful only as historical reference, not as active context. Some will be retired.

This is where technical leadership becomes more valuable than tool enthusiasm. The leader has to hold two truths at once: existing systems contain real institutional knowledge, and existing systems also contain old compromises that should not automatically shape the future.

The same tradeoff appears in build-versus-buy decisions. A team may already have a SaaS platform with embedded AI features. Another team may prefer a custom workflow because the risk, data, or integration requirements are specific. The useful question is not whether building or buying is more modern. It is which option lets the future workflow operate with enough clarity, control, and measurable value. I wrote more about that in build-versus-buy skills for AI software teams.

Starting from scratch is expensive. Carrying everything forward is also expensive. Pull-first scoping is the middle discipline: keep what earns its place.

Data Should Be Pulled By Purpose

Many AI projects treat data access as a completeness problem. The team tries to connect more sources, index more documents, expose more tables, and give the model broader context. More context feels safer because the model has more to work with.

That assumption is often wrong.

More data can mean more noise, more permission risk, more stale information, more conflicting definitions, more retrieval failures, and more evaluation burden. A model with access to everything may still answer from the wrong thing. An agent with too many tools may choose the wrong path. A data assistant with too many tables may generate queries that look plausible but do not match business definitions.

Pull-first data scoping asks what the future workflow needs to know, not what the organization can technically expose.

For a policy assistant, the purpose may require current approved policies, version history, ownership metadata, and escalation contacts. It may not require draft documents, private comments, or old copies from personal folders. For sales analysis, the purpose may require certified revenue metrics, customer segments, product hierarchy, and date logic. It may not require raw event tables for the first release. For software engineering support, the purpose may require repo context, coding standards, test output, and issue history. It may not require access to secrets, production credentials, or unrelated repositories.

NIST’s AI Risk Management Framework is useful here because it treats trustworthy AI as something to incorporate into design, development, use, and evaluation. Data scope is part of that design. It affects privacy, security, accuracy, explainability, and accountability.

The practical rule is simple: pull data because the workflow has a justified need for it, not because the connector exists.

Automation Should Be Pulled In Last

The most tempting part of an AI project is often automation.

It is easy to imagine the agent completing the task, updating the system, sending the email, closing the ticket, approving the exception, changing the forecast, writing the code, or submitting the report. That is where demos become exciting.

But automation should usually be pulled in after the team understands the decision, the evidence, the risk, and the review path.

There are at least four levels of AI assistance:

• Draft: The system prepares text, code, analysis, or a recommendation.
• Explain: The system shows sources, assumptions, confidence signals, or uncertainty.
• Recommend: The system proposes an action with supporting evidence.
• Act: The system changes another system or triggers a workflow.

Many projects should begin at draft, explain, or recommend. Acting can come later when the team has evidence that the workflow is stable enough.

This is not fear. It is sequencing.

If the assistant cannot retrieve the right policy consistently, it should not decide the policy exception. If the analytics system cannot explain which metric definition it used, it should not trigger executive reporting automatically. If the coding agent cannot pass tests and respect project conventions, it should not merge changes. If the support workflow cannot identify high-risk cases, it should not close tickets without review.

Pull-first thinking helps here because it does not ask, “How much can the model automate?” It asks, “Which level of assistance does the future workflow actually need now?”

Sometimes the answer is less automation than the team expected. That can still be a successful AI project if it improves quality, speed, learning, or user experience without creating hidden risk.

The Retirement List Is Part Of The Scope

Every AI project should produce two lists.

The first list is what the team will build, connect, clean, evaluate, and operate.

The second list is what the team will deliberately leave behind.

That second list is often missing. Teams document features, models, integrations, and milestones. They rarely document the old reports, duplicated documents, unused workflow branches, unclear metrics, manual status rituals, or abandoned pilots that should stop receiving attention.

Without a retirement list, the organization accumulates layers. The old dashboard remains because someone might need it. The new AI summary is added beside it. The manual approval remains because nobody wants to remove it. The agent drafts the message, but the old template still has to be filled out. The data product launches, but the spreadsheet continues to circulate because trust never moved.

Now the work is not simpler. It is heavier.

This is one reason internal AI systems should be treated like products, not ticket work. A product has lifecycle decisions. It has a target user. It has quality standards. It has adoption measures. It has support expectations. It also has pruning. Teams that want to go deeper on that operating model may find Treat Internal AI Systems Like Products useful.

The retirement list does not have to be aggressive. It can be staged:

• Stop adding new users to the old workflow.
• Freeze changes to a duplicated report.
• Mark a document set as historical and exclude it from retrieval.
• Replace one approval ritual with logged human review inside the new workflow.
• Archive an experiment after it fails defined criteria.
• Remove direct model calls once a gateway or evaluation process is ready.

Pruning is not glamorous, but it is part of making the future workflow real.

A Practical Scoping Sequence

If I were helping a team scope an AI or data workflow, I would keep the process short but explicit.

First, write the target workflow in plain language. Avoid tool names at the beginning. Describe who is doing the work, what they are trying to decide or complete, what information they need, what risk exists, and what a good outcome looks like.

Second, define the minimum trusted context. This includes documents, data, metadata, business rules, examples, policies, and system access. Do not ask what the model could consume. Ask what the workflow can justify.

Third, choose the assistance level. Decide whether the first release should draft, explain, recommend, or act. Be honest about the review burden. A draft that saves time and keeps a human accountable may be better than an autonomous action that nobody trusts.

Fourth, design evaluation before expansion. Build test cases, expected answers, trace review, cost tracking, latency targets, user feedback, and incident categories early. Evaluation is not a final exam. It is how the team learns whether the system deserves more responsibility.

Fifth, create the retirement list. Name what will be excluded, paused, archived, cleaned, or reconsidered later. This protects the team from dragging old complexity into the new workflow by default.

This sequence is deliberately ordinary. It does not require a new methodology. It requires the team to stop treating existing assets as automatic requirements.

The Takeaway

AI projects often fail under the weight of things that were never consciously chosen.

The team keeps the old workflow because it is familiar. It indexes every document because the connector is available. It adds a model because the vendor demo looked strong. It preserves approval steps nobody has reexamined. It lets an agent access tools before deciding what level of action the workflow can tolerate. It launches a new interface while the old spreadsheet continues to control trust.

That is inventory-first work. It starts from what exists and tries to carry as much forward as possible.

Pull-first thinking starts somewhere else. It asks what the future workflow needs to be useful, reliable, governable, and worth maintaining. Then it pulls in the data, tools, models, controls, people, and processes that support that future. Everything else has to wait, improve, or leave.

This is not a slower way to do AI work. In many organizations, it is the only way to avoid moving quickly in the wrong direction.

The point is not to build less. The point is to carry less by accident.