This is context engineering: designing the memory, structure, and feedback loops that let AI workflows keep working inside a real business.
A New Zealand construction tech founder was building what he called a cortex for his business.
The idea was simple: stop letting project knowledge live across PDFs, documents, spreadsheets, WhatsApp threads, and memory.
Instead, each project would be ingested into a structured second brain. Raw material, wiki notes, project YAML, key decisions, and working context would all sit somewhere the agent could use.
Even after only two projects, the effect was obvious.
The system was already faster than manually sifting through old PDFs, docs, and spreadsheets. The founder could ask better questions because more context had been pulled into a shape the agent could actually reason over.
But the more interesting part was not storage.
It was maintenance.
A second brain can become bloated. AI workflows drift. Project files change. Prompts get stale. Agents that worked last month quietly stop working because the business moved and nobody updated the system.
That is entropy.
So the work became about structure and feedback loops.
The founder started fixing defects in the ingestion process and adding clean YAML per project. The point was not to dump everything into memory. The point was to keep the memory usable.
Project work would get back-fed into the project folder. Co-working sessions with Claude would become smarter because the system had more structured context each time. New information would not just be chatted about and lost. It would be added back into the operating memory of the business.
That is the first loop.
Work happens. The agent helps. The useful context gets saved. The next session starts smarter.
But memory alone is not enough.
If AI workflows are going to run inside a real business, they need evals.
Not academic evals. Practical ones.
Did the workflow pull the right project context? Did it follow the structure? Did it avoid bloating the memory? Did it preserve the important decisions? Did it miss anything obvious? Did the output still match how the founder wants the business to operate?
These checks matter because agents degrade quietly.
A workflow can look like it is working while slowly getting worse. It can store too much, retrieve the wrong thing, ignore the important context, or produce outputs that feel plausible but are slightly off.
Without evals, you only notice when something breaks badly.
With evals, every failure can become a new check.
That is how you keep an AI workflow alive.
The founder did not need a magical agent that knew everything. He needed a business brain with structure, recurring ingestion, and a way to measure whether the system was still doing the job.
That is the shift.
The agent is not just a chatbot attached to a folder.
It becomes part of the operating layer of the company.
It remembers project context. It supports work sessions. It helps retrieve what matters. It creates a loop where the business can keep getting smarter instead of constantly starting from zero.
The lesson is simple: AI workflows need maintenance.
If you want them to survive real business use, build the loop early.
Ingest the work. Structure the memory. Check the outputs. Turn failures into evals. Keep the system clean enough that it can still be trusted later.
That is how you stop entropy from winning.