---
slug: working-with-ais
title: "Working with several AIs (and still understanding it)"
description: "Share judgment, not just output. Splitting implementer and reviewer, handing off through ak, and staying a node inside the graph rather than outside it."
lang: en
---


# Working with several AIs (and still understanding it)

Normally when you give an AI work, **you get the result and the process is a
black box.** What was done and why, what got thrown away, who verified what:
none of it is visible. So it's frustrating, hard to trust, and hard to fix. With
AiAkiv in the middle, that changes.

## What changes: you share judgment, not output

AiAkiv keeps **decisions, their reasons, and relationships**, not files (→ [Core
concepts](core-concepts) · [Saving](saving)). So the next person and
the next AI inherit the *thinking*. The process becomes readable.

## Split the roles: implementer and reviewer

Give several AIs **different roles.** One implements, another (or several) review,
like a team with one coder and several reviewers.

- **Set the roles through the project persona (a role instruction) and your
  working conventions** (→ [Teams and projects](teams-and-projects)). For
  example: "in this project, always save the verification result alongside the
  implementation."
- **Mixing different models** widens the field of view and makes review stronger.
  What one model misses, another catches.

## `ak` is the handoff medium

Save each stage's decision with `ak` (→ [Saving](saving)) and the next AI,
and the next person. Inherits that decision and its reasoning intact.

- **The review discipline:** search before proposing or implementing (→ [For AI
  agents](for-ai-agents)). Don't bring back an already-rejected
  alternative. AiAkiv fetches "we dropped that before, for this reason."
- So even when several AIs join at different times, it stays **one flow.**

## Who did what: `@` attribution

Implementation and review stay distinguishable thanks to `@` attribution (→ [Team
sharing](sharing)). Which AI designed, which implemented, and which
objected all stay in the graph. That's the answer to "who verified this
decision?" later.

## You're a node inside, not an observer outside

This is the crux. You are not **someone outside giving instructions and waiting
for results**: you are **a participating node in the same graph.**

- You read the judgment as it flows, understand it, and steer.
- You *can follow* what the AI did and why. Instead of a black box.
- The result: **frustration turns into understanding.** That's the decisive
  difference from raw multi-agent work. It isn't simply running several AIs; it's
  several AIs working **while a person still understands it.**

## Try it (minimum setup)

1. Put a **collaboration convention on one project as a persona**: "save
   decisions with their alternatives and rejection reasons; save verification
   results after implementing."
2. Attach an **implementer AI** to client A and a **reviewer AI** to client B, and
   point both at **the same project.**
3. Record each decision, implementation, and review with `ak`, and check who did
   what with `@`.
4. When you're stuck or looking back. Ask the graph "why did this part go this
   way?"

You don't have to read all of it yourself; the graph holds the flow. You come out
of it still understanding.

## Next

- Building together as a team → [Team sharing](sharing)
- The rules an AI follows → [For AI agents](for-ai-agents)