Nicolas Dominici

July 8, 2026

Before building an agent fleet, build four files.

Not a dashboard.

Not a vector database.

Not an orchestration layer.

Not thirteen agents with names, roles, profile pictures, and no real work to do.

Four files.

  • projects.yaml
  • decisions.md
  • inbox.md
  • weekly-review.md

That is enough to create the first layer of operational truth.

It will not impress anyone in a demo.

It will make the first agent much more useful.

Why files first

Agents need context.

But “context” is not a pile of random documents or infinite memory.

Context is current truth arranged in a way the system can use.

Most businesses do not have this. They have chat history, stale docs, disconnected tools, old spreadsheets, personal memory, and decisions buried in meetings.

Then they add an agent and expect it to operate.

The agent does what agents do in that situation: it sounds helpful and guesses too much.

Files force the operator to define the basics.

What projects exist?

What was decided?

What is waiting to be triaged?

What changed this week?

If those four questions are unclear, a bigger system will not save you.

It will only hide the confusion behind more infrastructure.

File 1: projects.yaml

The project registry answers one question:

What work is alive right now?

A simple version:

projects:
  - id: client-followup-system
    name: Client Follow-up System
    type: client_delivery
    owner: nico
    status: active
    priority: high
    next_action: Send implementation plan
    next_action_due: 2026-07-10
    last_reviewed: 2026-07-08
    source_of_truth: clients/acme/followup-system.md
    notes:
      - CRM stages need cleanup before automation
      - WhatsApp approval rules still pending

This file should be boring and strict.

Every active project needs:

  • ID;
  • name;
  • type;
  • owner;
  • status;
  • priority;
  • next action;
  • due date if relevant;
  • last reviewed date;
  • source of truth.

The project registry is not for brainstorming.

It is for work that is alive.

If a project has no next action, it is not active. It is a wish with metadata.

What an agent can do with it

An agent can:

  • list projects with no next action;
  • flag overdue work;
  • prepare a weekly priority review;
  • identify stale projects;
  • generate a follow-up list;
  • compare project priority against calendar time;
  • warn when high-priority work has not moved.

That is useful because the file is explicit.

File 2: decisions.md

The decision log answers:

What have we already decided, and why?

Most operators underestimate how much energy they waste reopening decisions.

Positioning. Pricing. Offers. Tools. Processes. Target customers. Hiring. Features. What to automate. What not to automate.

A decision log protects you from your own mood.

Template:

## 2026-07-08 — Reframe automation offer as business systems

Decision:
Stop selling isolated automation projects. Sell business systems tied to operational outcomes.

Context:
Buyers compare automation to cheap tools and implementation hours. The real value is reliable business behavior: follow-up, routing, reporting, document flow, response time.

Alternatives considered:
- Continue selling n8n workflows directly.
- Sell AI chatbots by channel.
- Productize one SaaS product immediately.

Reasoning:
Reusable systems compound. Custom workflows create delivery fragility. Outcome framing is clearer for buyers.

Review date:
2026-08-15

The reasoning matters more than the conclusion.

A conclusion without reasoning is just a note.

A decision with reasoning is operational memory.

What an agent can do with it

An agent can:

  • check whether new work contradicts previous decisions;
  • summarize why a direction was chosen;
  • prepare a strategy review;
  • identify decisions due for review;
  • prevent the operator from treating old debates as new insights;
  • explain context to another agent or collaborator.

That is not over-documentation.

That is leverage.

File 3: inbox.md

The inbox answers:

Where do raw thoughts land before they become work?

A common mistake is trying to organize ideas at the moment of capture.

That makes capture heavy.

Heavy capture dies.

The inbox should be fast, messy, and temporary.

Example:

# Inbox

## 2026-07-08

- Write essay comparing bad automation vs good systems.
- Follow up with ACME about CRM field cleanup.
- Potential template: four files for agentic operation.
- Check whether weekly review is too long.
- Idea: screenshot of OWL morning briefing for flagship essay.

No categories. No complex tags. No fake productivity.

Just capture.

Then triage on a schedule.

During triage, each item gets one of four outcomes:

  • convert to project/task;
  • add to decision log;
  • archive as reference;
  • delete.

Most ideas should die.

That is healthy.

What an agent can do with it

An agent can:

  • cluster raw ideas;
  • suggest what belongs in projects;
  • identify duplicates;
  • extract follow-ups;
  • prepare a triage list;
  • remind the operator that the inbox is becoming a junk drawer.

But the agent should not turn every thought into a task.

That is how systems become self-inflicted noise.

File 4: weekly-review.md

The weekly review answers:

What actually happened, and what changes next?

This file is the operating ritual.

Without review, the other files decay.

Template:

# Weekly Review — 2026-W28

## Planned

- Ship revised essays for personal site.
- Send two client proposals.
- Review follow-up system architecture.

## Actually happened

- Essays rewritten and packaged.
- One proposal sent, one delayed.
- Follow-up architecture clarified but not implemented.

## What moved

- Personal positioning now points to fractional systems engineer.
- Business systems framing is clearer than automation framing.

## What is stuck

- Need real screenshots / anonymized proof.
- Need one practical case study published.

## Decisions needed

- Which essay becomes the flagship post?
- Which system gets turned into a public case study first?

## Next week

- Publish flagship essay.
- Prepare one anonymized follow-up system teardown.
- Contact three companies with the systems offer.

The weekly review should be uncomfortable sometimes.

If it never creates tension, it is probably not connected to reality.

What an agent can do with it

An agent can:

  • compare planned work to calendar reality;
  • summarize what moved;
  • list stuck projects;
  • generate follow-up actions;
  • detect repeated blockers;
  • prepare the next week’s priorities;
  • ask sharper questions.

This is where agents become useful quickly.

A weekly review gives them rhythm.

The first agent

After the four files exist, add one agent.

Not a fleet.

One.

Give it a narrow job:

Read the four operating files every Friday. Produce a weekly operating report with: what moved, what is stuck, what needs a decision, what is overdue, what should be followed up, and what should be killed. Do not modify source files. Propose changes only.

That agent can create leverage because the system has something to read.

Without the files, the agent has to infer the business from chat history and vibes.

That is not an operating system.

That is improv.

When to add more

Add a second agent only when the first one has a stable job and produces external value.

Good reasons to add another agent:

  • a repeated workflow is now clear;
  • the source of truth is stable;
  • the handoff is defined;
  • quality can be reviewed;
  • the output changes real behavior;
  • failure modes are understood.

Bad reasons:

  • the role sounds cool;
  • the tool makes it easy;
  • you are avoiding sales;
  • the current agent is vague;
  • you want the system to feel more complete;
  • you are building infrastructure for status.

Agents should be hired by the operation, not by the founder’s imagination.

When files should graduate

Plain text is a starting substrate, not a religion.

Some things should eventually move elsewhere.

High-volume events belong in a database.

Customer records may belong in a CRM.

Secrets belong in a secrets manager.

Attachments belong in storage.

Production logs belong somewhere searchable.

Permissions need a real system.

But moving too early is expensive.

Files are useful because they force clarity before infrastructure.

Once the shape is stable, promote the parts that need stronger guarantees.

Do not promote confusion.

The real reason this works

These four files create a minimum operating system.

Not for the whole company.

For the operator.

They create:

  • visibility into active work;
  • memory for decisions;
  • a safe capture surface;
  • a weekly correction loop;
  • enough structure for an agent to help.

That is the foundation.

The agent does not create the operating model.

The files do.

The agent accelerates it.

I help companies build the operating layer behind agents: source-of-truth files, workflows, reports, integrations, permissions, and review loops. Use the four-file system as a starting point. If you want to turn it into a working business system, contact me.

You can also email me at nicolasdominici@outlook.com or DM me on LinkedIn.