In the early days of computing, the only way to get output from a mainframe was a report. People at green-screen terminals typed information in all week, and once a day the machine printed the sales report, the inventory report, the whatever report. It sounds primitive. I think we are about to rebuild it, and I think that is correct.
Here is the theory. As agents move beyond engineering into general knowledge work, the binding constraint is context: fast, cheap access to what the organization knows. Right now most teams handle this by dumping agent output into Slack, which is where structured information goes to die. A channel is a notification surface, not a record. You cannot accumulate on it, you cannot diff it, and next quarter's agent run cannot build on it.
Markdown files can do all of those things. Markdown is the most efficient way to express context for a model, it is nearly free to store, and it is fast to search with local compute. We already know agents can navigate codebases of hundreds of thousands of files successfully. There is no reason the same machinery cannot search hundreds of thousands of markdown documents holding sales history, support patterns, and operational state. You can always go back to source systems through APIs, but that is slow and expensive. A standing corpus of standardized reports, regenerated daily or continuously, gives every future agent run a cheap first layer of organizational memory.
This also settles where non-engineering agent work should live: in the same computer environment that engineering agents use today. Not a separate chat product bolted onto email. The same sandboxed machines, the same file-based context, the same review flow, because automating knowledge work is software engineering whether or not the task involves code. The substrate is identical even when the work is not, and the hard part remains getting organizational context into a form agents can actually use, the problem I laid out in the organizational context gap.
We are not in that world yet. But watch for it: the platforms that treat reports as durable files rather than disposable chat messages will compound context while everyone else keeps starting from zero.
Key takeaways
- The right environment for non-engineering agent work is the same computer engineering agents already run in, not a separate chat surface.
- Context for business tasks is best expressed as markdown, which agents can search as effectively as they search large codebases.
- Slack is where structured output goes to die, and standardized recurring reports are the pattern that replaces it.
FAQ
Why markdown instead of dashboards or chat summaries?
Because markdown is cheap to produce, cheap to store, and fast for agents to search with local compute. Agents already navigate hundreds of thousands of code files successfully. A corpus of markdown reports gives business context the same properties, with full history intact.
Isn't posting agent output to Slack good enough?
Slack is fine for notification but terrible for accumulation. Output dumped into channels has no durable structure and no history you can query. Standardized reports written to files give you a searchable record that future agent runs can build on.
Sources
Related Essays
The Organizational Context Gap
Across every agent platform, one layer is universally unsolved — organizational context. Not the prompt, not the model. The institutional knowledge an agent needs to do useful work.
Facts Rot. Reports Supersede. Build Memory Accordingly
Organizational agent memory needs rot and supersession semantics. Facts have lifespans, and the fresh report that replaces yesterday's is the format LLMs actually need.
Tech Context Is Tractable. Org Context Is Not
The hardest unsolved problem in agent infrastructure is not compute or sandboxing. It is context — and most of that context lives in people, not repos.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.