My view is this: workflow automation needs to cover at least three things at the same time — problem decomposition, task execution, and knowledge management — and they need to form a closed loop.

The starting point was actually very concrete: I found that managing TODOs purely in Markdown could no longer carry complex work. Markdown is good for ideas and conclusions, but it does not hold task state, dependencies, collaboration history, or intermediate decisions very well. That process information matters a lot while a task is moving, but most of it does not deserve to be stored directly in a long-term knowledge base after the task ends.

So my conclusion became: if I want my personal workflow to become an automated closed loop, I need to separate problem decomposition, task execution, and knowledge management, then connect them again in a deliberate way. After I connected Brains to Multica, that judgement became more concrete: Multica handles decomposition and collaboration, the agent runtime handles execution, and Brains distills and writes knowledge back. Together, they form a closed chain.

flowchart LR
    A[Problem / Idea] --> B[Multica\nSplit into issue / project]
    B --> C[Agent Runtime\nExecute task]
    C --> D[Task process\ncomment / log / decision]
    D --> E[Brains\nDistill / ingest]
    E --> F[Reusable knowledge]
    F -.query.-> B

If you follow that line of thought, the chain really has three parts: how Multica makes problem decomposition manageable, how the agent runtime picks up execution, and how Brains turns experience into reusable knowledge.

Multica gets problem decomposition into shape first

What interests me most about Multica has two layers. The first is simple: it is a very good kanban tool. Once I decided to pull task management out of Markdown, I needed a place that naturally expresses task status, dependencies, and collaboration history. Multica does that with almost no detour: issue, comment, project, repository, and parent/sub-issue are exactly the basic structures complex task management needs.

The second layer is more important: it is not just a board tool. It puts agents directly into the task flow. In other words, it does not only manage tasks. It makes agents first-class members of the task system instead of hidden capabilities behind a chat window.

That matters a lot. Many agent products are still basically “a human sends one prompt, then the system runs one flow.” Tasks, ownership, and context all get buried inside repeated conversations. That makes them hard to trace and even harder to reuse. Multica changes the entry point: issue, comment, assign. You can assign an issue directly to an agent and let it start working. You can also @brains, @planner, or other execution agents inside the discussion and pull multiple agents into the same task thread.

That turns the agent into a role that can be divided, coordinated, and tracked. For complex work, that matters more than “making the model a bit stronger,” because what teams usually lack is not one more answer in one round. They lack a collaboration structure that can last.

This step solves problem decomposition and task organization first: how a complex problem becomes an issue, how it keeps getting broken down, how it gets assigned, and how it keeps moving inside one shared thread. That is especially valuable in asynchronous, cross-project, multi-agent collaboration. Without this layer, so-called agent automation is usually just isolated capability calls, not a complete workflow.

Multica + agent runtime then connect automation to execution

The second thing that attracts me to Multica is that it does not try to invent a brand-new agent execution environment from scratch. Instead, it connects existing tools through daemon + runtime.

I see it as a more practical version of BYOA: bring your own agent. You can plug your existing agent runtime into Multica, then let assigned tasks run on that runtime. This has two immediate benefits.

• First, the execution environment becomes naturally distributed. Tasks can run on a specific runtime on a specific host instead of being squeezed into one centralized service.
• Second, existing agent toolchains can be reused directly. Whatever skills, MCPs, CLIs, or sandbox capabilities a runtime already has locally can be used during execution. You do not need to rewrite them just to integrate with the platform.

What makes this feel solid to me is that it boils down to two stable interfaces, and together they close the loop.

• application -> daemon -> agent runtime: if any application wants to use agent capability, it only needs to connect to an agent runtime through the daemon, and it can hand tasks to an existing execution environment.
• agent runtime -> tool -> skill/cli: if any agent runtime wants to use an external application, that application only needs to expose a tool, skill, or CLI entry, and the runtime can call it directly.

Once both directions are true, Multica, Brains, and the agent runtime stop being isolated points. You can start from any one application and call another application's capability, or keep composing them into serial, parallel, or even mesh-like structures to grow new products and capabilities over time.

flowchart LR
    subgraph Application
      A1[Application: Multica]
      A2[Application: Brains]
    end


    subgraph R[Agent Runtime]
        ReAct --> T[Tool]
        ReAct --> S[Skill]
    end

    D[Daemon]
    
    Application --> D 
    D --> R
    T --> C[Bash CLI]
    C --> Application

I like this abstraction because it is light enough. As long as the tool boundary is reasonably clear, you often do not need to rebuild the platform. You just add interfaces like daemon, CLI, and skill, and existing tools can join the agent workflow quickly.

What Brains adds is automated knowledge management

Having only a task system is not enough. An agent being able to execute does not mean it knows how to execute well. An agent solving a problem once does not mean that experience will remain in the right form.

That is exactly why I connected Brains to Multica.

Brains is essentially my own llm-wiki. I added a command-line entry for it — the Brains CLI — and turned knowledge-base reading and writing into stable interfaces that agents can call.

Then I created a brains agent in Multica and explicitly defined the Brains CLI calling style, use cases, and response structure. This agent does only two things: query and ingest. That makes Brains a knowledge role that can be invoked inside the task flow at any moment, not just a static documentation repository.

What this adds is not just “one more knowledge tool.” It adds knowledge-management automation. Task execution naturally produces a lot of process knowledge, but most of it does not deserve long-term storage. For example:

• temporary output from one command
• one failed attempt
• back-and-forth discussion used only to confirm context
• a temporary judgement made for the current environment

All of that matters during the task, so it should be fully carried by issue / comment / log. But if you write it directly into an llm-wiki without filtering, the knowledge base will quickly drift. What Brains needs to do is filter those process materials into conclusions, experience, constraints, and evidence that are actually worth keeping, then compress them into reusable knowledge pages.

That turns “problem decomposition -> plan discussion -> controlled execution -> experience compilation -> knowledge accumulation” into a real closed loop.

flowchart TD
    subgraph Task[Task domain]
        I[Issue]
        C[Comments]
        L[Logs / POC / Decisions]
    end

    subgraph Knowledge[Knowledge domain]
        S[Summary / Distillation]
        P[Brains Pages]
        Q[Query]
    end

    I --> S
    C --> S
    L --> S
    S --> P
    P --> Q
    Q -.Back to new task.-> I

A very concrete use case

For example, I create an issue: why kubernetes pod crashed.

The collaboration that follows can be very natural:

1. Assign it to @brains first so it can look up relevant runbooks, troubleshooting experience, and past cases from the knowledge base, then provide initial suggestions.
2. In a comment, call @planner and ask it to break the troubleshooting into actions, clarify which steps are read-only, which carry risk, and where I need to confirm.
3. Then hand it to the execution agent responsible for the work, such as @devops, and let it run the required actions after my confirmation.
4. Finally, ask @brains to summarize the incident and write the process and lessons back into Brains.

The most valuable part of this flow is that it turns troubleshooting into a process that is collaborative, replayable, filterable, and accumulative. In the past, a lot of operations knowledge died in chat logs, terminal history, and human memory. Now it can first be preserved as a task asset, then selectively distilled into a knowledge asset.

From a business perspective, these are really two naturally separate domains

At this point, the picture is clearer to me: task management and knowledge accumulation are equally important, but they should not be collapsed into the same system.

• The task system focuses on progress: who is doing the work, how far it has moved, what was discussed, what was decided, and what the execution result was. It naturally holds process information, and the fuller that process is, the better.
• The knowledge system focuses on compression and reuse: which conclusions are worth preserving, what the evidence chain is, what the confidence level is, and who can reuse it later. It naturally needs to de-process the material, and the more concise it is, the better.

If you treat task content directly as knowledge, you usually lose on both sides: the knowledge base gets drowned in process noise, and the task system loses contextual fidelity because it gets compressed too early.

So I prefer to think of this as the jira / confluence layering for the agent era: the former manages progress, the latter manages knowledge. The combination of Multica and Brains reconnects those two domains, and agents allow information to flow between them automatically.

Why this model really changed my workflow

I increasingly see Multica + Brains as a platform model rather than an accidental combination of two tools. The reason is simple: it neatly covers three layers of automation:

• Problem decomposition layer: Multica uses issue, comment, and assign to organize collaboration and split complex problems into tasks that can move.
• Task execution layer: Multica combines daemon + runtime to connect existing agent runtimes, security boundaries, and local capabilities.
• Knowledge management layer: Brains plugs retrieval, compilation, and accumulation into the same task chain.

Once those three layers are connected, the agent stops being just an executor. It participates in task delivery as a team member, then helps convert experience into genuinely reusable knowledge after the task ends.

What I especially value is the extensibility. As long as the interfaces remain stable, this model can be replicated across more scenarios:

• Add one layer of CLI + skill to any external system, and agents can learn to call it at relatively low cost.
• Add one daemon integration layer to any agent runtime, and a product can gain agent execution capability at relatively low cost.
• Add an issue/comment collaboration structure to any complex task, and humans plus agents can communicate inside the same thread instead of switching tools constantly.

From an engineering point of view, this feels more credible than “design one giant all-in-one super-intelligent platform first,” because each layer can evolve independently and be replaced independently. For me personally, the change is also very concrete: task management, agent execution, and knowledge accumulation used to be three separate things. Now they are connected into one chain for the first time, and I no longer need to move information manually. Agents can keep the loop moving within explicit boundaries.

Problems still unsolved

This model is already attractive, but a few things still need validation.

• How to make permission boundaries finer-grained. A role split such as planner read-only and devops writable is useful, but going further still requires clearer approval, audit, and rollback design.
• How to guarantee the quality of knowledge write-back. Not every issue-handling process deserves to enter the long-term knowledge base. Brains still needs clearer filtering and compilation rules.
• How to avoid noise in cross-agent collaboration. The more agents you add, the more comments and sub-issues can expand. The platform needs better routing, deduplication, and convergence.

None of these are small issues. But they also show why this path is worth pursuing: the platform problems that matter most usually show up only after the system already works.

Closing

If we treat agents only as smarter chat counterparts, what we get is mostly local efficiency gains. But once we place them at the intersection of the task system, runtime system, and knowledge system, they have a chance to become real collaborators.

For me, Multica solves “how to get agents into the task flow,” while Brains solves “how to let experience remain and continue creating value in the next task.” That is why I see this combination as a real workbench rather than a pile of tools that merely happen to call models.

Glossary

Term	Meaning in this article
Agent	A role in a task, such as brains, planner, or an execution agent
Agent Runtime	The tool or environment that runs an agent, such as opencode or claude code
Multica / Brains	The applications or systems themselves
Multica CLI / Brains CLI	Their respective command-line entry points
CLI	A call entry such as multica ... or brains query ...
Daemon	The bridge layer between Multica and the agent runtime