From First Principles to an Agent Harness

This is not another project breakdown. The first post already covered what I built. This one is about what I was really building underneath it.

The previous article in this series was the project story: the customer problem, the architecture evolution, the platform expansion, and the operational mistakes along the way.

I do not want to retell that story here.

This post is about a different question:

What was I actually building underneath all those features?

Looking back, the most interesting part of the project was not "building an AI agent." It was accidentally building an agent harness before I had the vocabulary for it.

At the time, I was not thinking in terms of graphs, runtimes, or orchestration frameworks. I was trying to solve one practical problem:

How do you make a real business system continuously ingest information, reason over it, execute actions, preserve state, and stay usable through the interfaces the user already lives in?

That is where the system started: not from AI abstractions, but from operational pressure.

---

This Post Is Not About Features. It Is About Layers.

Once the system moved beyond prototype mode, it became obvious that "chat with an LLM" was only a tiny part of the problem.

What the first post described as implementation work can be reframed much more usefully as five system layers.

1. Background execution

The first missing layer was background execution.

A real business system cannot depend on the user remembering to ask for everything manually. New data has to be pulled in, checked, summarized, and turned into action on a schedule.

That means the system needs a heartbeat before it needs elegance.

This was the first strong signal that I was no longer building a chatbot. I was building a continuously operating system.

2. An explicit action surface

The second missing layer was an explicit action surface.

Users do not think in low-level operations. They think in outcomes.

They do not ask for "query the database" or "read the file store." They ask for results: find the right customer, locate the right file, draft the right message, update the right stage.

So the system needed callable business capabilities, not just language understanding.

That changed the nature of the project. It stopped being "prompt an LLM" and became "give an LLM a controlled way to act on the business system."

3. A reasoning-execution loop

Once an action surface exists, static routing starts to break.

A classifier-router architecture works when tasks are simple one-step mappings. It breaks the moment tasks become conditional, multi-hop, or stateful.

That is when the core of the system has to become a loop:

• assemble context
• call the model
• inspect whether more actions are needed
• execute actions
• return results to the model
• repeat until the system has enough information to stop

At the time, I did not call that a harness.

But structurally, that is exactly what it was becoming: a runtime coordinating reasoning and execution.

4. Continuity

The fourth missing layer was continuity.

Business work is not stateless. A customer discussed today is still the same customer tomorrow. Stage matters. Previous replies matter. Recent automated workflow results matter. Human notes matter.

So a production system needs more than a prompt window. It needs continuity across turns, across customers, and across automated and interactive flows.

This is where many toy agents quietly fail. A demo can answer a question. A production system has to survive time.

5. Transport abstraction

The fifth missing layer was transport abstraction.

The development interface is rarely the user's real interface. If every new communication channel requires rewriting core logic, the system becomes fragile and unscalable.

That is why messaging eventually has to become an adapter layer, not the product itself.

This was one of the most important architectural shifts in the project.

Telegram was no longer "the bot." It became one transport inside a larger runtime.

That sounds small, but it changes everything.

---

The Hard Part Was Coordination

At first, each addition felt like a feature.

But at some point a pattern becomes impossible to ignore.

The hard part is no longer any individual component. The hard part is coordination:

• when should background workflows run?
• when should the system keep acting and when should it stop?
• how much state should move into the next step?
• how should outputs be adapted to each interface?
• how should external system responses be normalized for reasoning?
• what should stay automatic, and what should require human approval?

This is the point where the phrase "agent harness" becomes useful.

A harness is not just a collection of tools. It is the system that keeps reasoning, state, execution, and interface aligned.

---

Why Telegram + External APIs Matter More Than Most Agent Demos Admit

One reason I now describe the system as an agent harness is that it stopped being centered on the model very early.

The model matters, but it sits in the middle of a larger loop.

A real request moves more like this:

1. a user sends a message through an interface
2. session and context are loaded
3. the model decides what information or actions are missing
4. external systems are called
5. results are normalized
6. the model decides whether to continue or respond
7. the reply is adapted to the target channel and returned

That is not a single inference call.

It is a runtime coordinating an interaction surface and an execution surface.

This is why "chatbot + integrations" now feels like an underspecified way to describe what was built.

The platform is the interaction surface. The APIs are the execution surface. The model is the planner in between. The harness is the system that keeps those parts coherent.

---

Framework Vocabulary Became Useful Only After the System Existed

Only after building the system did names like LangGraph or agent harness become meaningful to me.

Before that, they were labels.

Afterward, they became useful because I had already lived through the underlying problems:

• state continuity
• action modeling
• iterative reasoning
• transport abstraction
• failure boundaries
• cost control
• human checkpoints

That changed how I think about frameworks.

I no longer see them as the starting point. I see them as one of two things:

• a shortcut that helps you avoid rebuilding solved infrastructure
• a vocabulary for patterns you have already discovered through real work

Frameworks are useful. But they are often overvalued too early.

The business problem should shape the runtime, not the other way around.

---

What First-Principles Agent Building Actually Means

If I had started from framework vocabulary alone, I probably would have made the system more elegant on paper and less useful in reality.

Because the real design constraints were never:

• should this be a graph?
• which framework should I adopt?
• what is the cleanest abstraction for tool execution?

The real constraints were operational:

• what state must survive?
• what actions must be executable?
• what belongs to automation and what belongs to a human?
• what workflows must keep running without the user asking?
• which interfaces does the system need to live through?
• what external systems actually change the world?

That is what I now think first-principles agent building really means.

Not starting from framework names. Starting from the minimum structure required for the system to remain useful under real constraints.

If you do that honestly enough, you may end up with something framework-like before you ever adopt a framework.

---

The Practical Takeaway

If you are building an agent system today, my advice is simple:

Do not start by asking, "Which framework should I use?"

Start by asking:

• what state must persist?
• what actions must be callable?
• what decisions must remain human-approved?
• what workflows must run in the background?
• what interfaces will the system operate through?
• what external systems actually matter?

Once those answers are concrete, the architecture starts to reveal itself.

And if you do it from first principles, you may discover — as I did — that you were never just building "an agent."

You were building the harness that lets one exist.