Playbook: Build a Vendor Research Agent That Remembers Every Session

Your procurement or account management team researches the same suppliers, carriers, or service providers over and over. Every conversation starts from zero. The analyst spends the first ten minutes re-explaining what the company already knows — which vendors are on the approved list, which ones failed a review last quarter, what risk flags are open, which rep they last spoke to. The institutional knowledge lives in emails, shared drives, and individual heads. This playbook walks you through building a subagent with its own filesystem that turns those scattered notes into a running research record the whole team can use.

What you will build

By the end of this playbook, you will have:

  • A subagent dedicated to vendor research, with its own filesystem scoped to just vendor work.
  • Custom tools that connect to your ERP or supplier management system and pull vendor records, historical orders, and open issues.
  • A structured filesystem layout: one folder per vendor, a decision memo for each evaluation, and a master index the agent maintains automatically.
  • A sandcastle app where the whole procurement team can browse vendor files without opening a chat.
  • A workflow where every new conversation with the agent starts with full context from the last one.

What you need before you start

  • An Assist workspace with your AI client connected via an MCP server. If you have not connected one yet, follow Creating an MCP server.
  • Editor access to create a new agent and turn its filesystem on.
  • API credentials for the supplier system the agent will read from. This is usually your ERP's supplier module, a dedicated supplier management platform, or a homegrown vendor database.
  • A rough list of the vendor fields that matter to your team: legal name, D-U-N-S number, primary contact, onboarding status, approved product categories, current risk flags, last review date. You will use these to structure the files.

This playbook uses a fictional supplier API at https://erp.internal.company.com/api/vendors as the example. Substitute your real system.

Step 1: Create the agent and turn its filesystem on

Before writing any tools, set up the subagent. From your AI client, tell the MCP server you want a new agent:

"Create a new subagent called 'Vendor Research Agent'. Its purpose is to research suppliers, keep notes across sessions, and help the procurement team decide whether to onboard or continue working with a vendor. It should never place orders, send money, or change anything in the ERP — read only."

The AI will create the subagent and return its ID. Then, in Assist, open Agents, click the new agent, scroll down to Filesystem Volume, and turn the switch on. Start a fresh chat with the agent and confirm the file tools are available by asking: "do you have file tools? list them."

The agent should respond with the ten file tools: read, write, edit, glob, grep, move, copy, remove, link, and curl.

Step 2: Decide the filesystem layout up front

Before the agent starts writing anything, spend one conversation designing the layout. A consistent structure is the difference between "useful archive" and "pile of notes nobody trusts." Tell the agent:

"We are going to use your filesystem to keep vendor research notes. I want to agree on a layout before you start writing files. Here is what I propose:

  • /index.md — a running index of every vendor we have researched, sorted alphabetically, with one line per vendor: legal name, status, last review date, link to the vendor folder.
  • /vendors/<slug>/profile.md — the core facts: legal name, D-U-N-S, primary contact, approved categories, onboarding status.
  • /vendors/<slug>/history.md — a running log of every interaction and decision, newest first.
  • /vendors/<slug>/risks.md — open risk flags, each with a status (open, mitigated, closed) and a date.
  • /vendors/<slug>/decisions/<date>-<short-title>.md — one file per decision memo, so we can see every decision we have ever made on this vendor.

Whenever we research a new vendor, you should create the folder, write these files, and update /index.md. Whenever we come back to an existing vendor, you should read profile.md, history.md, and risks.md first so you have context. Does that layout work?"

The agent will confirm or propose changes. Iterate until you are happy. This one conversation saves hours of confusion later.

Step 3: Build read tools that connect to your supplier system

The agent needs to pull real data from the ERP, not just take your word for it. In your AI client, create tools:

"Create a custom tool called get_vendor_record that takes a vendor ID or name, calls our ERP at https://erp.internal.company.com/api/vendors/{id} using bearer token auth, and returns the vendor record as JSON. Include: legal name, D-U-N-S, primary contact name and email, approved product categories, onboarding status, created date, and the most recent review date."

"Create a custom tool called list_vendor_orders that takes a vendor ID and a date range, calls the ERP at https://erp.internal.company.com/api/orders?vendor={id}&since={date}, and returns each order with: order number, date, total value, line item count, fulfillment status."

"Create a custom tool called get_vendor_risk_flags that takes a vendor ID and returns any open risk flags recorded on the vendor, with flag type, severity, opened date, and the current status."

Test each tool against a known vendor to confirm the data shape is what you expect. Iterate if the ERP fields do not match what the agent is pulling.

Step 4: Research the first vendor

Now start the actual work. Pick a vendor you know well so you can sanity-check the agent's output.

"We are starting research on Acme Logistics. Use get_vendor_record to pull their record, list_vendor_orders for the last twelve months, and get_vendor_risk_flags for any open flags. Then create the folder structure we agreed on and write the profile, history, and risks files. Include a decision memo called initial-review.md summarizing whether they look healthy based on the data. Finally, update /index.md to add this vendor."

The agent will call each tool, write the files, and report what it did. Open each file (ask "read /vendors/acme-logistics/profile.md") and verify the content matches reality. If the agent got something wrong, correct it in the chat and ask it to update the file.

This is the iteration loop you will use for every vendor. The agent gets better at it as you tune the prompts.

Step 5: Come back a week later and test the memory

This is the whole point of the filesystem. Close the chat, wait a day or a week, then open a brand new chat with the same agent. Do not remind it of anything.

"I want to continue researching Acme Logistics. What do we already know about them?"

The agent should check /index.md, find the Acme Logistics entry, read profile.md, history.md, and risks.md, and summarize everything it previously wrote. If it does not, prompt it to "check your filesystem first before answering." After a few conversations the agent will do this naturally without prompting.

Now add something new:

"Acme just missed a delivery deadline for order 87421. Log this in their history and open a risk flag for delivery reliability."

The agent will edit history.md to add a new line at the top and create a new entry in risks.md. Read both files back and confirm the changes. This is the durable loop: every interaction adds to the vendor's record without the analyst having to remember to update anything.

Step 6: Build a sandcastle app for the whole team

Individual analysts talking to the agent is useful. A browse-able front end for everyone in procurement is transformative. Tell your AI client:

"Build a sandcastle app called 'Vendor Research Browser' that lets the procurement team read the vendor files our agent has been writing. The app should:

  • Call a tool that lists every vendor folder under /vendors/ and reads each vendor's profile.md.
  • Display a sortable, searchable table of vendors with columns: legal name, onboarding status, last review date, open risk count.
  • When a row is clicked, open a detail view that shows the full profile, the history file as a scrolling feed, and the list of open risks.
  • Pull the vendor files through a new read-only tool that uses the agent's filesystem tools to fetch each file.
  • Store a per-user bookmark list as persistent state so analysts can mark the vendors they are watching.

The app should be read-only — all writes go through the agent in a chat. This is the audit surface, not the edit surface."

The AI client will scaffold the app. Iterate: "move the risk count column next to status." "Make rows with any open critical risk red." "Add a filter for onboarding status." Each prompt refines the app through conversation.

Share the app with your procurement team. They can now browse every vendor's research without ever opening a chat, while the underlying files stay under the agent's management.

Step 7: Schedule a weekly review agent

The filesystem is perfect for agents that run on a cron schedule. Create a second agent that runs weekly and reviews every open risk flag:

"Create a new subagent called 'Vendor Risk Reviewer' scheduled to run every Monday at 9 AM. Give it Execute access to the Vendor Research Agent's filesystem by sharing the Vendor Research Agent with it. The Monday job should:

  • Read every /vendors/<slug>/risks.md file.
  • For each open risk, check whether its status has changed in the last week based on the timestamps in the file.
  • Write a weekly summary to /reviews/<date>-weekly-summary.md listing: new risks opened this week, risks that moved to mitigated, risks still open from more than 30 days ago.
  • Post a short summary to the procurement Slack channel with a link to the summary file."

Now the agent does a thing every Monday without anyone remembering to ask. The filesystem is the coordination layer between the Monday agent and the analyst agent — both read and write to the same structured set of files.

What you built

At this point the procurement team has:

  • A research agent that starts every conversation with full context from every prior conversation, because its memory is on disk instead of in the LLM context.
  • A structured archive of every vendor the team has ever evaluated, written in plain text, searchable, and recoverable even if the agent is turned off.
  • A browseable app for the whole team that makes the archive visible without a chat.
  • A scheduled reviewer that runs every week and flags what is new.

What used to be "a bunch of emails and nobody remembers" is now "a subagent with a living knowledge base." The filesystem is the part that makes it durable.

Natural extensions

Once the loop is working, there are a handful of obvious next moves:

  • Onboarding checklists: one file per step, the agent walks new vendors through the list and tracks progress.
  • Contract expiration tracking: a tool that reads contract end dates from the ERP, a weekly agent that creates a risk flag 60 days before expiration.
  • Spend analysis: a monthly agent that reads the order history for every vendor and writes a spend summary to /reports/<month>-spend.md.
  • Handoff files: when the primary analyst takes a vacation, they can tell the agent "write a handoff file for /vendors/acme-logistics/ with the current state," and the covering analyst starts the next chat with that file.

The agent and its filesystem become the persistence layer for the whole procurement workflow. Every extension is just a new prompt.

Related guides