I’ve just finished building the first working version of my LinkedIn operation harness.

This is also the first post coming out of it.

The idea started with a simple question:

Instead of building one AI agent that does everything, what if I treat personal online presence as a small agent system with clear responsibilities?

The current architecture

Four roles

There are four distinct roles behind the workflow.

Personal Assistant
The main agent. It maintains my cross-platform persona and long-term goals, and decides which specialized agent should handle a task.

LinkedIn Operator
Responsible specifically for LinkedIn: applying the persona to the channel, maintaining relationship context, and preparing interactions and content.

Tech News Tracker
Continuously gathers information from blogs, GitHub repositories, news sources, and other primary sources. It provides fresh context instead of asking the LinkedIn agent to search for everything itself.

Dev
Builds and maintains the capabilities that the other agents use. I currently use coding agents such as Codex and Copilot here.

Why the boundaries matter

The important part for me is the boundary between these roles.

I don’t want one giant agent with an enormous prompt trying to remember everything. Persona, goals, channel operations, information gathering, and engineering capabilities have different lifecycles and should be maintained separately.

The harness and shared state connect them together.

At this stage, the system is still semi-automated. I intentionally keep human review in the loop while I observe how the agents behave over longer periods of time.

What’s next

This is only the first iteration, and probably the first of several posts about what I learn while building it.

I’d also love to exchange ideas with people working on agents, harness architecture, developer tooling, or automation.

And not only AI.

I’m a full-stack engineer, so I’m always happy to discuss the less glamorous details too — backend systems, data engineering, Flink, infrastructure, frontend, integrations, or simply why a seemingly small engineering decision became surprisingly complicated.

More experiments and implementation details to come.