Inside my AI agent setup: LoopEngineering, Harness

A reply is only the start of a workflow.

That sounds obvious until you try to run more than one task through an AI system. A chat can give a good answer. It does not tell me where the task belongs, which tools should be available, what evidence remains after the work, or when I need to step back in.

So I stopped treating every request as a chat.

I am building an internal environment around a set of role-specific agents. It is still evolving. Some parts are rough. But it already gives me a better way to route work, keep context, and review what comes back.

This is the current setup.

Why I stopped treating every task as a chat

A general assistant is useful when the task is small and the context is obvious. The problems arrive when the work has a history, a deadline, a codebase, a report to write, or a decision that affects someone else.

I currently work with roughly ten agent profiles. Development, content, research, computer vision, monitoring, and other functions each have their own working context.

The separation is practical. A development task should begin with a repository, an implementation brief, and a way to check the result. A research task needs sources and a confidence boundary. Content work needs the originating evidence, the audience, and a review before anything goes public.

Putting all of that into one permanent conversation creates a mess quickly. The agent may still answer. I lose the operating context around the answer.

Discord is where the work starts

Discord is the visible layer of my setup.

I use it to interact with the different agent roles and keep conversations attached to a domain. If I am thinking through a product decision, working on content, or asking for a development task, the request starts in a place that already carries some context.

That matters because the conversation stays available after the first response. I can ask for a revision, challenge an assumption, or pass the work to another role without rebuilding the whole situation from terminal history.

Discord is not where I want the system to remember everything forever. It is the interface where work enters the environment.

Obsidian is the shared dashboard

Obsidian is where the work becomes visible as an object rather than a message.

The agents can update tasks, write reports, and leave suggestions there. I can see the goal behind a task, its project, the evidence used, and what still needs review. That gives me a shared place to return to when a conversation has moved on.

For me, this is the difference between using agents casually and building a working environment around them. The system needs a place where a task can live after the agent has finished typing.

It also keeps me in control. I can read the result, correct the framing, reject a conclusion, or decide that the task needs a human instead.

Hermes gives the roles a place to run

Hermes is the role-based agent environment behind the interface.

The Main Agent is my main point of interaction. It has the broader view of the system and can decide which specialist should handle a request. That does not remove my responsibility for the request or the result. It gives the work a route.

The setup runs in the cloud, outside one laptop session. I care about that for continuity. A task, a report, or an agent conversation should not disappear because I closed a terminal window.

I am deliberately keeping the infrastructure details out of this article. The useful lesson is operational: a shared environment gives agents somewhere consistent to work, and gives me somewhere consistent to inspect that work.

The Developer Agent is my AutoWorker

The Developer Agent is a Hermes agent. It is also the AutoWorker in this setup.

I do not interact with it directly. I work through the Main Agent. When a request needs development work, the Main Agent can pass the task into the Developer Agent loop and bring back the result for review.

The Developer Agent uses Superset to manage the development workspace and agent session. It uses OpenCode for the coding work itself.

That distinction matters. Superset and OpenCode are tools inside the loop. They do not replace the agent that owns the task context, the permissions, the checks, and the final report.

A coding loop still needs boundaries. Which repository can it access? What change is allowed? What should it test? What does it need to report back? A generated patch without those answers is hard to trust, even when it compiles.

Memora gives durable context a different home

Long-term memory is useful. Permanent chat history ages badly as a memory system.

I use Memora as the long-term memory layer in the architecture. The idea is simple: store the full, approved knowledge in a rich memory value, then make it retrievable through a short primary abstraction and several cue anchors.

A confirmed preference can be retrieved when it matters. A decision about a codebase can be found through the project name, the repository, or the technical choice behind it. A proven workflow can reappear when a similar task arrives weeks later.

This avoids turning every chat, raw log, or temporary task update into permanent agent context.

Obsidian remains the source of truth for the human side of this process. It holds the report, the evidence, and the approval trail. Memora holds stable knowledge that has earned a place beyond the original task.

The current setup treats this as a memory representation layer. I am not presenting it as a separate local Microsoft Memora service. The discipline matters either way: durable memory needs an approval path, a source, and a reason to exist.

The controls after the answer

The interesting work starts after an agent produces text, code, or a recommendation.

I need to know what the agent was asked to do. I need to know which tools and data it could access. I need a trace of the output, a way to correct it, and a point where I decide whether anything happens outside the system.

Those controls are less exciting than a demo. They are also where an agent workflow becomes usable in real work.

I saw this clearly during an early construction-sector engagement. The scope included work with plans, selected normative constraints, measurements, and business context. The goal was to make certain steps more readable and easier to review. Expert judgment stayed with the person responsible for it.

That experience changed how I think about the setup I am building now. Agents can prepare work. People still need to understand the boundary, inspect the result, and own the decision.

What I am still changing

This remains an internal build. I am still testing it against real work.

I am still learning which roles deserve their own agent, which handoffs create more friction than they remove, and what evidence each kind of task should leave behind. I am also learning where memory helps, where it adds noise, and when a simple conversation remains the better tool.

I am preparing an AI Agent Harness Engineering offer for CTOs and technical founders who want to assess an agent workflow before expanding it. The work will focus on the same questions I am testing in my own environment: scope, permissions, evidence, review points, and the conditions under which an agent should stop.

If your team is building an agent workflow and you want to examine the operating layer before you give it more responsibility, message me.