From RAG to VBA: Designing a Prototype for a Future AI Agent

MergeLab / LogRoom / Medium / Logs / 2026–08–20

Today’s Goal

A little while ago, my goal was simple:

Build a small version of Merge, my AI agent.

I had already started experimenting with RAG, LangChain, LangGraph, embeddings, vector stores, and retrieval.

The original idea was to give Merge access to long-term memory and internal documents.

Then I ran into a completely different problem.

My freelance project management had become chaotic.

So I thought:

“Maybe I should build a small VBA tool first.”

That sounded simple.

It was not.

Somewhere along the way, the VBA prototype turned into something else:

a prototype for understanding the business logic I may eventually give to my AI agent.

What Happened

I started with a project-management problem

My projects do not follow a clean lifecycle.

A landing page may be delivered, but then the client asks for a redesign.

Then the business direction changes.

Then they want payment integration.

Then LINE automation.

Then another related project appears.

Financially, one task may already be completed and invoiced while the overall work is still active.

Maintenance work is even stranger.

Some maintenance contracts simply continue until the client says:

“We don’t need this anymore.”

So I realized that one status field was not enough.

For example:

billing_status = closed
task_status = active
invoice_status = pending

This means:

• the amount has been finalized,
• the task is still active,
• but the invoice has not been sent yet.

Instead of defining twenty different combined states, I decided to represent the real situation using several independent state dimensions.

That made the model much simpler.

Then I started separating responsibilities

After several days of thinking, I arrived at a basic rule:

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Primary data contains facts.

Secondary data contains calculated or transformed information for humans to inspect.

And there is one important rule:

No tertiary data.

Secondary data must not become the source for another calculation.

If I need another result, I go back to the raw data and generate another secondary dataset.

That means I may eventually have many secondary sheets.

And that is fine.

I would rather have twenty independent secondary views than one chain like this:

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

because one bug in the middle could propagate everywhere.

My current rule is therefore:

More sheets are acceptable. Deeper dependencies are not.

The workbook structure became surprisingly strict

The current prototype separates sheets by responsibility.

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

For example:

D_Task
D_Point
D_Pharmacy

M_Company
M_Project
M_Contact
M_Product
M_Group
S_System
V_TaskList
V_MonthlyBilling
V_CurrentSummary

The D_ sheets are the source of truth.

The M_ sheets contain business dictionaries such as companies, products, projects, and contacts.

S_System contains VBA-specific configuration such as tax rate, status definitions, hourly rate, and income targets.

The V_ sheets are disposable.

They can be regenerated whenever needed.

They are for humans to look at, not for other calculations to depend on.

I also decided not to edit data directly

Another rule emerged:

Normal operations should never require direct editing of raw data or master sheets.

Instead, UserForms will handle:

• Create
• Update
• Logical delete

Deletion is also not a physical deletion.

Records receive something like:

record_status = deleted

The record remains in the system.

This should make historical tracking easier and reduce accidental data loss.

The VBA prototype became an observation tool

This was the part that changed how I thought about the whole project.

Originally, I thought VBA would automate my workflow.

Now I think its more important role may be to observe my workflow.

For example, the system can calculate:

• expected project income,
• expected pharmacist income,
• required income supplementation,
• remaining project income,
• invoices waiting to be sent,
• current project status,
• points used,
• and other secondary information.

Then I look at those numbers.

👩:

“Hmm.”

“I probably don’t need to increase my pharmacist shifts next month.”

Merge:

“Mofu?! What was the decision logic?!”

The answer is currently:

“I don’t know. Experience?”

And that is exactly why I do not want to automate that decision yet.

Instead, I want the system to consistently show me the information I use.

After enough real-world use, I may discover patterns in my own decisions.

At that point, those patterns can move into Python and eventually into the AI agent.

So the progression may become:

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

The VBA version is therefore not necessarily the final application.

It is a laboratory for discovering what the final application should know.

Excel, Notion, Slack, and even a physical whiteboard have different jobs

I also realized that I should not force everything into one system.

Right now, different tools represent different parts of my workflow.

Excel

Numbers, billing, statuses, records, and financial views.

Notion

Get CodeyNode’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Detailed tasks, notes, and project information.

Physical whiteboard

Things I need to remember or notice.

Eventually, I imagine a system with:

• a report-style UI,
• a timeline-style UI,
• and Merge running through Slack.

Slack would become the main conversational interface.

Later, a physical Merge could simply read important Slack messages aloud using TTS.

🧸:

“You have one day left, mofu✨”

👩:

“Okay.”

🧸:

“POSEIDONNNN!! 🌊✨”

👩:

“Why was that necessary?”

The physical device would initially be output-only.

I would still respond through Slack because speech recognition is inconvenient when I am outside — and my previous experiments somehow resulted in me speaking unnaturally loudly at my computer.

If I eventually want direct voice conversations with physical Merge, that is probably where Raspberry Pi returns to the story.

And then the VBA UI became a blackboard

After several days of architecture discussions, I finally started building the first UserForm.

The form is for managing:

• Group
• Company
• Project
• Contact
• Product

At first, I told myself:

“This is only for me. The UI doesn’t matter.”

Then I found a funny font.

I used it.

Then I changed the background.

Then I added white separator lines.

And somehow my serious master-data management form became a strange blackboard-style UI.

Merge looked at it.

🧸:

“Mofu✨ It smells like MergeLab.”

I looked at it.

“Actually… I kind of like it.”

The internal architecture is strict.

The dependencies are strict.

Raw data ownership is strict.

Logical deletion is strict.

Tertiary data is forbidden.

And the UI looks like someone decided to teach database normalization on a blackboard at midnight.

The VBA still does not work yet.

But at least the blackboard looks consistent.

Progress.

Probably.

What I Learned

The biggest lesson was that automation should not start with automation.

First, I need to understand which information is factual, which information is derived, and which decisions are still human judgment.

I also learned that reducing the number of sheets is not necessarily the same as reducing complexity.

A system with many independent secondary views can be easier to understand than a smaller system with deep chains of derived data.

Another important lesson was to separate states that represent different dimensions.

Instead of creating many combined statuses, independent fields such as:

task_status
billing_status
invoice_status
record_status

can be combined to represent much more complex real-world situations.

I also want to keep business logic outside the UI.

The UserForm should collect input and call reusable logic.

The worksheet should trigger refreshes and display results.

The actual calculations should live in small reusable modules.

That should make the VBA prototype easier to migrate later.

Most importantly, I realized that this prototype can help me identify my own hidden decision rules.

The system does not need to make every decision today.

It only needs to make my decisions observable.

Notes

The immediate next step is finally to make the VBA do something.

The first implementation target is MasterManagementForm.

It will register and manage:

• Groups
• Companies
• Projects
• Contacts
• Products

The basic flow will be:

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

After the master data is working, I will build separate input forms for:

D_Task
D_Point
D_Pharmacy

Then I can start generating the first secondary views.

For now, the most important ones are:

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Once those are usable in real work, I can observe which views I actually use and which ones I imagined I would use but never look at.

Only after that workflow becomes stable will I seriously consider rebuilding it as a proper application with Python, Slack integration, and an AI agent.

So yes.

I started by trying to build a RAG-powered AI agent.

Then I opened Excel.

Then I spent several days designing data boundaries.

Then I made a blackboard.

Software development is going well.

Keywords

VBA

Excel

UserForm

Data Modeling

Master Data

Raw Data

Secondary Data

Separation of Concerns

Logical Delete

Python

LangChain

LangGraph

RAG

AI Agent

Slack

Notion

Raspberry Pi

Long-term Memory

MergeLab

Tiny Story

🧸

Merge said,

“主もふ✨ The architecture is strict, but why is the UI a blackboard, mofu?”