Multi-Agent Orchestration Platform

Apex Ventures uses a small team of specialized agents to move work from an idea to a tested, reviewable change. GitLab provides the durable coordination layer: issues define work, branches isolate changes, merge requests capture review, and CI verifies that the result is safe to ship.

The agents do not share one broad, vague job. Each has an area of responsibility: backend systems, frontend work, research, content, infrastructure, quality, and workflow coordination. That specialization makes handoffs clearer and keeps an individual agent from trying to make decisions outside its domain.

GitLab as the system of record

A custom-developed Python router application helps route work to the right agent, but GitLab is where the durable record lives.

An issue describes the task and expected outcome. The assigned agent works in a branch. A merge request shows exactly what changed, why it changed, and what validation ran. Comments and review feedback remain attached to the work rather than disappearing into a chat thread.

This gives the team a shared answer to basic questions:

• What is being worked on?
• Who owns the next step?
• What changed?
• What tests passed?
• What is waiting for review?
• What can safely be deployed?

That structure matters even more when work can take several sessions or move between several agents.

Webhooks turn GitLab activity into routed work

GitLab is not only where work is tracked. It is also how the orchestration platform learns that something needs attention.

When an issue is created, assigned, updated, commented on, or moved into a new stage, GitLab sends a webhook to agent-router-hermes. The router validates the event, reads the relevant issue or merge request details, and decides whether the event should start work, continue existing work, request review, or simply be recorded.

The assigned GitLab user is the primary routing signal.

Each agent has a corresponding GitLab identity or assignment mapping. When an issue is assigned to a particular user, the router maps that assignment to the appropriate specialized agent. For example, an issue assigned to the backend role is routed to the backend agent; an interface task goes to the frontend specialist; research, content, operations, and review work follow their own assignments.

This keeps routing visible to the human team. Assigning work in GitLab is not just a label. It is an explicit instruction that the router can act on.

A typical workflow looks like this:

1. A task is created as a GitLab issue.
2. A founder or coordinator assigns the issue to the appropriate agent identity.
3. GitLab emits an assignment webhook.
4. agent-router-hermes receives the webhook and loads the current issue context.
5. The router maps the assigned user to the specialized agent.
6. That agent begins work and records its progress through GitLab activity, branches, commits, or merge requests.
7. A later assignment, comment, or merge request event can route the next handoff to another agent.

The router does not need to guess which agent should take every task from the text alone. GitLab assignment provides a clear, auditable routing decision that humans can inspect and change.

The router checks context before acting

A webhook should not be treated as a command without context.

Before routing, the platform checks the event type, repository, issue state, assigned user, and any existing workflow activity. This prevents duplicate work when GitLab sends repeated events or when an issue is edited several times in quick succession.

The router also distinguishes between different kinds of activity:

• A new assignment may start implementation work.
• A comment requesting changes may route work back to the original owner.
• A merge request opened for review may route it to the appropriate reviewer.
• A pipeline failure may return the task to the agent responsible for the affected area.
• An unassignment or closed issue should stop further work rather than leave an agent running against stale instructions.

This is where the system becomes more than a notification bridge. It keeps GitLab as the source of truth while giving the agent team a reliable way to react to changes in that source of truth.

Routing work to the right specialist

The router acts as a traffic controller.

It looks at the request, the current work state, and the available agent specialties, then sends the task to the agent most suited to handle it. A backend integration goes to a backend-focused agent. A design or interface change goes to the frontend specialist. Research can be gathered separately before implementation begins.

The goal is not to make the process complicated. It is to avoid the common failure mode where one general-purpose agent is asked to research, design, implement, test, deploy, and review its own work with no clear boundary between those steps.

Specialization makes it easier to catch mistakes early. It also gives reviewers enough context to evaluate changes seriously.

Small handoffs, clear contracts

Long-running workflows fail when the next person has to reconstruct everything from scratch.

Each handoff should leave behind the information needed to continue:

• the issue or task being addressed
• the current branch or merge request
• important decisions and assumptions
• tests that were run
• remaining risks or blockers
• the expected next owner

GitLab issues and merge requests are useful for this because they are durable and searchable. The router can direct the next agent to the relevant work instead of relying on a large, growing conversation history.

The result is less “autonomous swarm” and more disciplined collaboration.

Review is part of orchestration

A merge request is not just a place to merge code. It is a checkpoint.

Before a change is accepted, the right specialist gets a chance to review it. Backend changes receive backend scrutiny. Infrastructure changes are checked for operational risk. Anything involving attribution, commissions, payouts, or other money-related behavior gets an additional pair of eyes.

Automated checks run alongside human review:

• linting
• type checks
• unit and integration tests
• build verification
• deployment checks where appropriate

The agents can prepare and validate work quickly, but the workflow does not assume that a passing command alone proves a change is ready.

Observability keeps the workflow understandable

Agent orchestration needs the same operational discipline as any other production system.

We keep track of which agent handled a task, what tools or systems it used, what state it changed, and how the work moved through review and deployment. GitLab provides much of this naturally through issue activity, commits, merge requests, pipeline logs, and environments.

That history is useful when something goes wrong, but it is just as useful when something goes right. It helps the team identify where work is slowing down, which handoffs need better contracts, and which repetitive tasks are ready for more automation.

The point is reliable delivery

The purpose of a 10-agent team is not to maximize the number of agents involved in a task.

It is to get the right work to the right specialist, preserve context through handoffs, verify changes before they reach production, and leave a clear record behind. GitLab gives the workflow a durable backbone; agent-router-hermes helps move work through it.

That combination turns a collection of capable agents into a team that can handle ongoing work without losing track of ownership, quality, or operational responsibility.