The most important part of my agent system is not the agents.

Not the model. Not the orchestration. Not the memory layer. Not the integrations. Not the scheduled jobs.

It is the pile of plain text files.

Markdown. YAML. Git. Decision logs. Project registries. Generated dashboards. Small files that say what is true.

That sounds less impressive than “thirteen agents running my company.”

It is also the reason the agents can do anything useful.

Agents need something to stand on

An agent without context is a talented intern on their first day.

It can sound smart. It can ask reasonable questions. It can produce plausible work. It can improvise.

It does not know the business.

It does not know what was decided last month. It does not know which project matters most. It does not know which ideas were killed. It does not know what “done” means. It does not know which source is canonical. It does not know when a document went stale. It does not know what the operator will regret automating.

Unless the system gives it that context.

Plain text becomes infrastructure here.

Not because Markdown is beautiful.

Not because YAML is fun.

Not because Git is fashionable.

Because plain text creates a durable, inspectable, versioned layer of operational truth.

The database is often the wrong first move

When people imagine building an agentic operating system, they often start with a database.

Tables. Schemas. APIs. Vector stores. Dashboards. Admin panels. Permissions. A proper backend.

Sometimes that is necessary.

Often it is premature.

Early systems change too fast. Categories are unstable. Workflows are not understood yet. The operator is still discovering what should exist.

A database makes premature structure feel official.

Plain text stays negotiable.

A project can start as a YAML entry. A task can start as a Markdown checklist. A decision can become a dated note. A weekly review can be generated text. A dashboard can be rebuilt from registries. A skill can be edited, diffed, reviewed, reused.

The system stays legible while the operating model is still forming.

Start with files.

Promote to databases when the shape has earned it.

What this looks like

A project registry does not need to be impressive.

It needs to be clear.

projects:
  - id: followup-system-acme
    name: Follow-up System for ACME
    owner: nico
    status: active
    priority: high
    client_visible: true
    next_action: Send revised implementation plan
    next_action_due: 2026-07-10
    source_of_truth: /clients/acme/projects/followup-system.md
    last_reviewed: 2026-07-08
    risks:
      - CRM fields are still inconsistent
      - WhatsApp ownership rules need client approval

That file gives an agent something to inspect.

It can ask what is overdue. It can generate a follow-up list. It can detect missing owners. It can compare last review dates. It can build a weekly report. It can warn that a project marked high priority has no next action.

The format is boring.

That is the point.

Git is operational memory

Git is a developer tool until it becomes operational memory.

It answers questions that chat history cannot answer cleanly:

• What changed?
• When?
• Who changed it?
• Why?
• What did the file say before?
• Which decision caused this direction?
• Did we already try this?
• Is this plan new, or an old loop with better wording?

Humans reopen settled questions when they are tired, anxious, bored, or avoiding real work.

A decision log is a defense against that.

When positioning changes, write the reasoning down.

When an offer is killed, write the reason down.

When a workflow is frozen, write the reason down.

Not because documentation is virtuous.

Because future-you is not a reliable witness.

A simple decision log can look like this:

## 2026-07-08 — Freeze custom automation projects as a category

Decision: Stop selling isolated automation projects. Reframe the offer around business systems.

Reasoning:
- Buyers compare automation to tools and cheap implementation.
- The real value is reliable business behavior: follow-up, routing, visibility, response time.
- Reusable modules compound better than bespoke workflows.

Rejected alternatives:
- Keep selling n8n workflows directly.
- Sell generic AI agents by channel.

Review date: 2026-08-15

That is not bureaucracy.

That is memory with a spine.

Plain text makes agent work reviewable

A prompt hidden inside a SaaS tool is hard to govern.

A skill stored as a versioned file is different.

You can diff it, review it, roll it back, copy it, improve it, assign it to another agent, ask another model to critique it, tie it to an evaluation, and see when it changed.

That is the difference between prompting as improvisation and prompting as infrastructure.

If an agent’s competence lives only in a chat thread, it does not compound.

If it lives in files, it improves like code.

I care about operational knowledge as versioned assets, not prompt engineering as a hobby.

Views should be generated from truth

One of the best decisions I made was separating source of truth from view.

The source of truth is structured text.

The dashboard is generated.

Truth is not edited in the dashboard.

Truth is displayed there.

Beautiful dashboards become the database if you let them. Every change becomes UI work. Every new field becomes a product decision. Every correction requires clicking around. The system gets heavier than the work.

With registries and generated views, humans and agents update structured files.

Reports and dashboards regenerate from those files.

The interface can change without destroying the underlying truth.

Why this works with agents

Agents are good with text.

Obvious, and still underused.

They read Markdown. They update YAML. They summarize logs. They compare decisions. They generate reports. They inspect diffs. They notice contradictions. They propose edits.

Plain text has an unfair advantage because it gives agents a simple surface area.

The agent does not need to “use the project management app.”

It needs to update projects.yaml according to a rule.

That is a much easier thing to trust.

Plain text is not enough

Plain text does not replace everything.

It is not ideal for high-volume transactional data. It is not a permission system by itself. It is not a substitute for backups. It is not good for concurrent edits without discipline. It is not where customer secrets should casually live. It is not a replacement for a real database when the system reaches that stage.

“Everything should be Markdown” is another religion.

I do not need one.

Plain text is a strong first substrate for operating knowledge, especially while the system is still becoming itself.

Later, some parts should graduate.

Customer data may belong in a CRM.

Events may belong in a database.

Secrets belong in a secrets manager.

High-volume logs belong somewhere searchable.

But the operating model should be legible before it becomes infrastructure.

The boring stack compounds

The attractive part of agent systems is live behavior.

The agent replies. The workflow runs. The report arrives. The bot captures the idea. The integration updates the record.

The compounding part is boring.

A cleaner registry.

A better decision log.

A more precise skill.

A deleted stale file.

A dashboard generated from truth instead of vibes.

A weekly report that compares the plan to reality.

A rule that prevents new infrastructure unless external work demands it.

Not demo material.

Operating leverage.

What I would build first

If I were starting again, I would not start with an agent fleet.

I would start with four files.

projects.yaml

Every active project, owner, status, priority, and next action.

decisions.md

Dated decisions with the reasoning, not the conclusion alone.

inbox.md

A capture surface for raw thoughts, later triaged into the system or deleted.

weekly-review.md

A ritual that compares the plan against reality and decides what changes next week.

Then I would add one agent.

Not thirteen.

One agent that reads those files and produces something externally useful: a follow-up list, a proposal draft, a weekly operating report, a publishable essay, a client-ready summary.

The files create continuity.

The agent creates leverage.

You need both.

Why boring survives

Plain text is underrated infrastructure because it is boring enough to survive.

It does not try to own the company. It does not lock truth inside a product. It does not require a roadmap. It does not break when a SaaS changes pricing. It does not need a new tab. It does not impress anyone in a demo.

It keeps the system legible.

In an agentic operation, legibility is what keeps intelligence from turning into noise.

---

I build operating systems around real business work: files, workflows, agents, integrations, reviews, and the boring infrastructure that keeps everything legible. If your company needs the system behind the AI, contact me.

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