For years, “multi-agent” on a laptop has usually meant one model taking turns wearing several name badges—or a local interface quietly sending the difficult work to a cloud API.
Kynd now does something materially different. A main agent can keep a real Build run moving on the Mac’s GPU while a small local companion keeps the conversation responsive and read-only specialists work in background lanes. When the selected runtime offers multiple safe inference slots, Kynd can use those too.
No research prompt needs to leave the machine just because the builder is busy. No cloud model has to impersonate the “team” behind a local badge.
“One Mac. A real agent team. Kynd can build, research, review and keep the conversation alive across local inference lanes—while persistent Alive agents keep watch over the project. No cloud hand-off. To our knowledge, it is a world first for a Mac-local agent workspace.”
Two local models generating at once.
2 models generating
A team is not a prompt with job titles.
We use “agent” carefully. A specialist in Kynd gets a bounded task, an allowed tool set, its own lifecycle and a result that survives until it has actually been delivered. Research and review agents are read-only. A test specialist receives execution access only when a genuine second engine is available.
If there is no independent lane, Kynd says so. It returns the work to the main agent as inline guidance instead of claiming that a background agent ran. That honesty is part of the architecture, not a footnote.
Separate work
Each specialist gets a concrete brief, role and safe tool surface—not a theatrical label inside the main prompt.
Separate lifecycle
Running tasks are never reaped by a short timer. Finished results stay until the main agent has received them.
Separate capacity
Kynd derives the safe fan-out from the Mac’s memory, loaded model sizes and real server slots instead of hard-coding a fantasy team size.
If a second agent did not run, the interface should never tell you that it did.Kynd engineering principle
Different silicon. Different jobs.
Apple Silicon gives the system an unusual advantage: one machine contains several useful compute lanes and one pool of unified memory. Kynd treats that as a scheduling problem, not merely a benchmark number.
The main, larger model owns the high-value path: reasoning, files, code and tools. A small GGUF companion can run CPU-side for chat, voice and read-only delegated work while the GPU model continues its Build run. Because the work happens on different local lanes, the conversation does not have to freeze every time the builder takes the GPU.
There is a second route too. With a llama.cpp server configured for multiple slots, separate sequences can share the loaded weights through continuous batching. Kynd only uses that pool when the runtime reports enough slots; a single-slot server is not presented as concurrent.
Concurrency without turning the Mac into a space heater.
Spawning agents is easy. Keeping the machine useful while they run is the hard part. Kynd measures available capacity from total memory, the model packs currently loaded and the number of inference slots the companion actually exposes.
A single priority queue sits in front of CPU inference. Delegated user work comes first, visible foreground chat comes next, and speculative background activity comes last. Higher-priority work may stop an idle warm-up or background heartbeat, but it never tears down user-visible work already in progress.
The subagent cap is also admission control, not a queue of agents pretending to work. If this Mac can safely run one background model request, the tracker shows one. It does not show three “active” agents while two wait behind a single server slot.
The work stays steerable.
A Build delegation opens the same real run you would start from the Build tab, with the same tools, permission mode and live activity. It does not gain new authority because it began in Chat. The run stays visible, and you can redirect or stop it.
Background specialists are deliberately narrower. They can read, search and browse; the test role is the single exception and only receives its shell tool on a separate engine. Every task has a status, owner and report. The result is merged back into the main thread instead of disappearing into an orchestration log.
Alive agents keep the project warm.
The foreground team handles work you ask for now. Alive agents are the persistent background layer. On a heartbeat, an Alive agent reads the project’s real signals—changed files, recent commits, failures and test coverage—then takes the highest-priority specialist job the project actually calls for.
That might mean reviewing work in progress, finding an untested change, mapping the active area or checking startup health. Coverage keys stop it repeating the same review on files that have not changed. When there is genuinely nothing new, it rests.
01HeartbeatRead current project signalsDONE
02Changed files found3 files · active worktreeDONE
03Map the active areaCallers · tests · configWORKING
04Report to Agents panelPath:line evidence readyQUEUED
Alive work runs through the CPU companion lane at background priority. It yields to delegated and visible foreground work, never grabs the GPU as a fallback, and returns read-only findings for the host to record. That is how an agent can stay awake without making the Mac feel occupied.
Why we are calling it a world first.
“World first” is a large claim, so here is the exact one we are making: to our knowledge, Kynd is the first Mac-local agent workspace to combine a large on-device builder, a separate responsive local companion, bounded background specialists, real multi-slot fallbacks and memory-aware scheduling in one user-facing system.
We are not claiming that nobody has ever run two models on a Mac, built a local agent loop or used llama.cpp parallel slots. The breakthrough is the product-level combination: the hand-offs, safety boundaries, cache behaviour, capacity checks and live interface that make those pieces act like one coherent local team.
That is what changes the feel of local AI. You stop waiting for one model to finish being everything. You start working with a system that knows which part of your Mac—and which level of authority—each job deserves.