Reo Brain: The Smart Company Core We're Building Inside Reotech

The problem

Most business AI starts with a chat box: connect a model, upload some documents, start asking questions. That can be useful, but it was never the problem we wanted to solve at Reotech.

Our real problem wasn’t access to information. We already had the information — spread across seven systems that had never been introduced to each other.

Where a single decision actually lived

1. Plane
2. Forgejo / GitHub
3. CI
4. Deployments
5. Observability
6. Infrastructure
7. Reo Brain

A client decision, the work that followed it, the implementation, the CI run, the deployment, and the production behavior it caused all lived in different tools. A person can connect those pieces. Software usually cannot. And a normal AI conversation certainly cannot — not unless somebody spends ten minutes explaining the company to it again, every single time.

Reo Brain is our attempt to make the company itself understandable to AI — not by replacing our tools with one enormous application, but by creating an intelligence and orchestration layer between them.

Why a chat box wasn’t enough

From an AI helper to a smart company core

The original idea was much smaller: take project notes, structure them, find relevant previous work, and prepare a first technical draft so an engineer starts from something better than a blank page.

That’s useful. But once we connected AI to real company systems, a much more interesting question appeared:

What if the AI understood what was happening across the company without waiting for us to ask?

A pull request is never just a Git notification. It means a piece of work may now be ready for review. If the review rejects it, that work needs attention. If CI fails, the feature isn’t ready. If it passes, gets approved, and the eventual deployment causes a production problem three weeks later, that incident is connected to a deployment, which is connected to a pull request, which is connected to a work item, which is connected to the original requirement and client decision.

Today, humans maintain most of those relationships mentally. Reo Brain is designed to maintain them as part of the system.

One operating layer, many existing tools

We are not trying to rebuild GitHub, Plane, monitoring, or CI inside an AI product. Each tool already has a job. Plane manages work. Forgejo and GitHub manage code and collaboration. CI runners build and test software. Trigger.dev handles durable background workflows. Our infrastructure runs applications and internal services, monitoring systems observe them, PostgreSQL holds structured operational state, Qdrant provides semantic retrieval when knowledge cannot be represented as a simple relation, and local models provide reasoning where software rules alone are not enough.

Reo Brain sits across those systems. Its job is to understand what happened, what it belongs to, what it means, and what should happen next.

That distinction turned Reo Brain from an AI feature into an internal platform.

What runs today — and what doesn’t yet

Most case studies blur this part, so let’s be precise instead: Reo Brain is an active build, and pretending otherwise would misrepresent it.

Running today

The foundation is production infrastructure we rely on daily:

• local AI compute running inference through OMLX on hardware we control;
• private source control through Forgejo, with GitHub where client projects require it, plus dedicated CI runners;
• Trigger.dev for durable workflows, PostgreSQL for structured operational state, Qdrant for semantic retrieval;
• Langfuse tracing the AI layer itself, alongside normal application observability.

On top of that foundation sit connected engineering workflows and the first specialized agents — each with a bounded domain, its own context, and explicit operating rules rather than unrestricted access to everything.

Being built now

The current phase is the hard part: the shared operating layer that turns separate capabilities into one company system — the unified event pipeline, the context and knowledge graph, agent orchestration, tools and permissions, and the evaluation loop that tells us whether an agent actually got better or just produced a nicer demo.

Most likely the proportions between “running” and “being built” will look very different in six months. Writing the plan down anyway is how we hold ourselves to it.

How we’re building it

Specialized agents, not one AI with access to everything

One of the easiest ways to build a dangerous AI system is to create one giant agent and give it every tool. We took the opposite approach: Reo Brain is designed around specialized agents with explicit responsibilities.

An infrastructure agent needs deep knowledge of our servers, networking, storage, containers, DNS, deployments, monitoring, and operational standards. It does not need access to every commercial discussion. An engineering agent may need source code, repository architecture, tests, CI results, coding standards, technical specifications, and pull requests. A planning agent needs project goals, client requirements, historical decisions, dependencies, previous estimates, and implementation patterns.

The important part is that they don’t exist as unrelated chatbots. They share an operating layer. They receive the right context, use approved tools, hand work to deterministic workflows, request human decisions — and their actions trace back to the event and information that caused them.

AI only where AI is actually useful

A system becoming “agentic” does not mean asking an LLM to run every step. If a pull request is approved, software does not need artificial intelligence to change a work item’s status — that’s a deterministic event, so we automate it normally.

AI becomes valuable when the next step requires interpretation: why did CI fail? Does this implementation satisfy the requirement? Is this incident related to yesterday’s deployment? Are two requirements contradictory? Should this situation reach a human?

That separation is fundamental to the architecture. Normal software handles what is known. AI handles ambiguity. It makes the system cheaper, faster, easier to test, and much safer than putting a model in the middle of every operation.

The event-driven pipeline

Instead of a person constantly prompting an assistant, Reo Brain listens to signals the company already produces — requirements changing, branches opening, reviews requesting changes, CI failing or passing, deployments shipping or breaking, monitoring detecting anomalies, operational knowledge being created.

Those events enter workflows that validate, normalize, enrich, and connect them to known entities. Only when reasoning is required does an appropriate AI capability get involved. Long-running work moves through durable orchestration instead of relying on a single HTTP request or an agent staying alive indefinitely.

Signal → Context → Reason → Plan → Act → Verify → Learn

1. 01

   Signal

   A company event happens: a requirement changes, CI fails, a deployment ships, monitoring flags an anomaly.

   • Plane
   • Forgejo / GitHub
   • CI runners
   • Monitoring
2. 02

   Context

   The event is normalized and connected to the project, work item, repository, and history it belongs to.

   • PostgreSQL
   • Event graph
3. 03

   Reason

   Only when interpretation is required, an appropriate model investigates, explains, or classifies.

   • Local models
   • OMLX
4. 04

   Plan

   A next step is proposed: an explanation, a fix, an update, or an escalation.

   • Specialized agents
5. 05

   Act

   Low-risk actions execute automatically through deterministic tools and workflows.

   • Trigger.dev
   • Internal tools
6. 06

   Verify

   Every decision, tool call, and outcome is traced so behavior can be inspected and evaluated.

   • Langfuse
   • Observability
7. 07

   Learn

   The outcome becomes part of the company's operational memory for next time.

   • Qdrant
   • Knowledge layer

Not prompt → model → hope. Reason is the only stage that calls a model, and only when the step ahead actually requires interpretation.

Access is not authority

For an agent to participate in a company, generating text isn’t enough — it needs capabilities. Depending on its role, a Reo Brain agent may read project state from Plane, inspect work items and repositories, search technical documentation, retrieve previous decisions, examine pull requests, read CI logs, check deployment state, query monitoring, create structured internal information, start predefined workflows, prepare proposed changes, or ask a human to approve something sensitive. We’re exploring MCP alongside native APIs and internal services as ways to expose those capabilities through clear contracts.

But access is not automatically authority. An agent being technically capable of performing an operation does not mean it should be allowed to perform it.

Reasoning, tooling, permissions, and approval are separate layers. That lets us automate aggressively where risk is low without applying the same policy to production changes, destructive operations, or client-sensitive decisions.

The knowledge layer

A useful agent should not rediscover Reotech every morning. But simply stuffing thousands of documents into a prompt isn’t intelligence either.

Reo Brain separates different kinds of memory. Structured information — projects, environments, repositories, work items, ownership, events, deployments, agent runs, and their relationships — belongs in structured systems where it can be represented explicitly. Long-form knowledge such as architecture documents, project specifications, runbooks, infrastructure notes, previous incidents, implementation decisions, and lessons from completed work needs semantic retrieval to surface a small relevant set when an agent needs it.

The objective is intentionally not “give the model everything we know.” It is:

give the model the smallest set of reliable information required to make this decision well.

More context is not necessarily better context. A smaller, well-selected context can outperform a huge prompt full of unrelated company history.

Local AI as part of our infrastructure

Some of the most valuable information Reo Brain can access is also some of the information we least want to send indiscriminately outside the company: client requirements, source code, internal architecture, incidents, business decisions, and work performed under confidentiality agreements.

That’s why local AI is not a marketing checkbox for us — it’s part of the architecture. Reotech runs its own model infrastructure, including inference through OMLX on our own compute.

Local-first also doesn’t mean routing everything through one enormous model. Different jobs have different requirements: a small model may classify or route an event, another may handle structured extraction, a vision-capable model may process documents or screenshots, and a more capable reasoning model earns its cost only on difficult technical investigations. Many workflows shouldn’t call a model at all. Where an external model is appropriate and the data policy permits it, that stays an explicit capability rather than an architectural dependency.

How it behaves

A concrete trace

Architecture diagrams hide the interesting moment, so here is the shape of one: a pull request opens in Forgejo, the pipeline links it to its project and work item, CI fails, and the engineering agent starts investigating without being asked.

1. event pull_request.opened auth-service · feature/sso-refresh → main
2. context context assembled linked work item, requirement, repo history, prior decisions
3. event ci.failed 3 tests failing in session middleware
4. agent engineering agent invoked reads failing logs, changed files, CI output, requirement
5. action explanation proposed session cookie regression — root cause + suggested fix drafted
6. result work item updated status → changes requested, root cause attached

The agent didn't wait to be asked. The failing build was enough to start the investigation.

The result: the project stops being a collection of disconnected screens and becomes a living operational graph of what the company is doing — where a later problem can be traced backward through the decisions that produced it, instead of living in whoever remembers.

This is the actual thing we’re automating, by the way. Not engineers — the coordination work surrounding them: the repeated checking, the context gathering, the status synchronization, the searching through old decisions, the manual work required simply to understand the current state of something. That frees people for the work where judgment matters: architecture, product decisions, client communication, debugging, trade-offs, and building.

Observability for agents

Traditional monitoring asks whether the request succeeded, how long it took, and which service failed. Agentic systems add another category entirely: what did the agent know before it acted? Which documents were retrieved? Which model decided, which tools did it call, what did they return? Did it retry? Was human approval required, and was the recommendation accepted?

If an AI system participates in real operations, those details cannot disappear inside a black box. We use AI-specific tracing and evaluation alongside normal application observability so agent behavior can be inspected and improved.

Models change. Prompts change. Retrieval and tools change. The system therefore needs evaluation the way normal software needs tests — the goal is improving an agent because evidence shows it became better, not because a new model produced a more impressive demo.

Human control is part of the system

Agentic does not mean autonomous by default. We classify actions by consequence: reading CI logs is low risk, suggesting the probable cause of a failure still relatively low risk, updating a work item after an authoritative repository event can often be deterministic. But preparing a code change is different from merging it. Recommending an infrastructure change is different from executing it. Restarting a safe internal workload is different from modifying production networking.

Low-risk work disappears into automation. Higher-risk work ends in a proposal. Critical work requires an explicit human decision. Every category still benefits from better context and faster analysis.

The goal is controlled autonomy, not maximum autonomy.

Architecture

The infrastructure behind the idea

The agent layer only works because it sits on real operational infrastructure. Reotech operates its own development and server environment — Forgejo with GitHub support where needed, dedicated CI runners, a private container registry, and servers separating networking, applications, storage, and monitoring.

How the layers fit together

Existing systems

Each tool keeps doing its job.

• Plane
• Forgejo / GitHub
• CI runners
• Trigger.dev
• Infrastructure & monitoring

→

Reo Brain core

Understands what happened, what it means, what should happen next.

• Event pipeline
• Context & knowledge graph
• Agent orchestration
• Tools & permissions
• Observability & evaluation

→

Model layer

Selected per task, not per platform.

• Local inference via OMLX
• Task-specific routing
• External models where permitted

Reo Brain doesn't replace this stack — it sits across it, so every existing tool keeps its job.

Reo Brain is not replacing those systems. It is connecting them into something more useful than the sum of their dashboards.

Where it’s going

From internal AI tools to an agentic company core

1. Phase 1

   Local AI foundation

   Built the local model and internal infrastructure foundations needed to run AI Operations workloads on systems controlled by Reotech.

2. Phase 2

   Connected engineering workflows

   Connected more of the engineering lifecycle around projects, repositories, CI, deployments, internal knowledge, and operational services.

3. Phase 3

   Specialized agents

   Moved away from generic assistants toward bounded agents with specific responsibilities, context, tools, and operating rules.

4. Current

   Agentic operating layer

   Building the shared event, context, orchestration, knowledge, observability, and permission layers that allow those agents and services to work as one company system.

A system that gets better as the company operates

The final piece of the architecture is the feedback loop:

• A completed project creates useful knowledge.
• An incident creates useful knowledge.
• A corrected AI recommendation creates useful knowledge.
• A rejected plan creates useful knowledge.
• A deployment outcome creates useful knowledge.
• A human decision creates useful knowledge.

That does not mean letting a model rewrite its own memory whenever it produces an answer. Useful knowledge needs provenance — we need to know whether something came from an authoritative system, a human decision, an observed event, retrieved documentation, or an AI inference.

The long-term value of Reo Brain is that the operational system becomes richer as Reotech works: the next project benefits from the previous one, the next incident benefits from how a similar one was resolved, and agents begin with actual company context instead of generic knowledge.

Why build all of this internally?

Because this is also how we want to build AI for clients.

• Not a chatbot attached to a database.
• Not a collection of prompts.
• Not “AI-powered” added to a product page.

We’re interested in systems where AI understands the specific operations of a business and works alongside the software already running it. For a logistics company, that could mean understanding deliveries, drivers, exceptions, documents, vehicles, and operational workflows. For a finance product, understanding documents, transactions, contracts, recurring obligations, and reconciliation while keeping deterministic financial rules outside the model. For another company, the core could look completely different — the architecture adapts because the company’s operations become the foundation.

Reo Brain is where we build and operate those ideas on ourselves first.

The outcome

And the history generated by that entire process can become useful context for whatever happens next.

For a non-technical person, the idea is simple: less time spent coordinating software, more time spent doing useful work.

For us technically, the interesting challenge is making that promise real without creating an uncontrolled AI black box — combining event-driven software, durable workflows, local inference, structured data, retrieval, specialized agents, explicit tools, permissions, observability, evaluation, and human approval into one system.

That is what Reo Brain is becoming.

And before we build this kind of infrastructure for someone else’s company, we want it running ours.