I finally gave my AI agents a shared memory and a team #Crew44

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built Crew44 — a free, local-first orchestrator that turns the AI coding agents already installed on your machine into one coordinated crew.

The original itch was pretty simple: I had too many smart tools and not enough shared context.

At one point I had Claude Code, Codex, Cursor Agent, GitHub Copilot CLI, and a few others all available on the same machine. Each one was useful. Each one had different strengths. But using them together felt weirdly manual.

Open a terminal. Paste the repo context. Explain the conventions. Get an answer. Copy the useful bits somewhere else. Open another agent. Explain the same thing again. Ask it to review. Paste the result back. Repeat tomorrow.

It felt less like working with a team and more like onboarding a brand-new contractor every single morning.

Crew44 is my attempt to fix that.

Instead of treating each agent as a separate silo, you create a small crew of named specialists — for example:

• Partner for planning, memory, and coordination
• Engineer for implementation
• Product Lead for scope and tradeoffs
• Designer for UX and polish
• Reviewer for checks and second opinions

Each specialist can be bound to the runtime and model that fits the job. One role can use GitHub Copilot CLI, another can use Claude Code, another can use Codex, another can use a local model. They all work inside one shared workspace.

The parts I care most about:

• Per-project memory
  Crew44 remembers useful facts about a project, so the same conventions do not need to be re-explained forever.

• Shared skills across providers
  A workflow can be captured once as a SKILL.md file, attached to an agent, and reused across turns. The idea is that skills should compound instead of disappearing after every session.

• Right model, right role
  Planning, coding, reviewing, and design feedback do not always need the same model. Crew44 makes it easier to assign the expensive or powerful models where they actually matter.

• Structured handoffs
  Agents do not just dump a giant transcript into the next context window. They pass structured handoff notes: what happened, what changed, what still matters, and what the next specialist should do.

• A Partner that watches for improvements
  Crew44 can review run history and suggest new memory, skills, or routing changes. Those suggestions are queued for explicit approval. Nothing gets written without an Accept / Edit / Snooze / Dismiss decision.

And it is intentionally local-first.

Crew44 runs on your machine. State lives in plain files under ~/.crew44/. There is no account, no subscription, and no telemetry. The only network calls are the ones your chosen coding agent CLI would already make.

It is also MIT-licensed and free, with desktop builds for macOS, Windows, and Linux.

Demo

• Download: crew44.io/download
• Source: github.com/getcrew44/crew44

📹 Embed product video here:
https://crew44.io/download/crew44-intro-v3.mp4

Here is the core idea: a crew of specialists, each with its own runtime, model, skills, and purpose.

🖼️ Agents

A task in progress looks like a shared workstream instead of a pile of disconnected chats. Specialists can stream work, hand off, and continue the same task from different angles.

🖼️ Tasks

And the Partner’s “Auto” suggestions show the loop I wanted from the beginning: the system learns from usage, but waits for me to approve what becomes persistent project knowledge.

🖼️ Auto suggestions

Under the hood, Crew44 is an Electron + React desktop app talking to a Go daemon over WebSocket JSON-RPC. The daemon is responsible for discovering installed agent CLIs, spawning them, normalizing their output, and routing their messages into the shared Crew44 workspace.

I also built an Expo mobile app that can pair to a running desktop session over an end-to-end encrypted tunnel, mostly because once the crew was running, I wanted to be able to check in from my phone too.

The Comeback Story

Crew44 did not start as a product.

It started as a junk drawer.

I had shell aliases, terminal layouts, half-written scripts, copied prompt files, old notes, and a bunch of “temporary” workflows that were somehow still part of my daily coding routine months later.

The messy version worked just well enough that I kept using it. That was the problem.

It was good enough to limp along, but not good enough to share. Every useful piece was trapped in my own setup. Every improvement made the system slightly more powerful and slightly harder to explain to anyone else.

The Finish-Up-A-Thon gave me the push to turn the pile into something real.

The big before/after was this:

Before:
Crew44 was a private tangle of scripts, terminals, duplicated rules, and manual copy-paste between agents.

After:
Crew44 is an installable local-first app with a real runtime layer, shared project memory, reusable skills, structured handoffs, signed desktop builds, docs, a changelog, and a public repo.

The most important things I finished were:

1. Real handoffs instead of copy-paste

The old workflow was basically “copy whatever seems relevant and paste it into the next agent.”

That does not scale.

Now agents can produce structured handoff documents with the current goal, context, useful details, suggested next steps, and timestamped notes. The next specialist can pick up the baton without needing the whole transcript dumped into its context window.

2. One runtime layer for many agent CLIs

I replaced the “whatever command I happened to type today” approach with a Go runtime interface.

That made it possible for Crew44 to support multiple backends behind one picker, including Claude Code, Codex, Cursor, Gemini, GitHub Copilot CLI, and others.

The important part is not just that there are multiple backends. It is that Crew44 treats them as peers. A Copilot-backed specialist, a Claude-backed specialist, and a local-model-backed specialist can all participate in the same workflow.

3. Shared skills that travel across providers

This was one of the main reasons I wanted Crew44 to exist.

I was tired of maintaining the same instructions in different formats for different tools. The same coding rules, review expectations, project conventions, and workflow notes kept getting copied into separate places.

Crew44 uses skill folders so that a workflow can be written down once and attached to the agents that need it.

That makes the system feel less disposable. When I learn how I want a task done, I can capture it, reuse it, and improve it over time.

4. Something people can actually install

This was the least glamorous part and probably the most important part.

I added signed desktop builds, a download page, a public repo, a changelog, and enough structure that someone else can try it without cloning my dotfiles and hoping their machine looks like mine.

That is the real comeback for me: from “private workflow I can barely explain” to “local app someone else can download, inspect, and run.”

My Experience with GitHub Copilot

GitHub Copilot helped Crew44 in two ways.

First, Copilot helped me finish the product itself. I used it heavily for the unglamorous work that usually slows down the last mile: wiring adapter code, tightening TypeScript types, checking edge cases, drafting tests, and moving repeated patterns into cleaner abstractions.

The second part is more interesting: GitHub Copilot CLI became a first-class runtime inside Crew44.

That means a Crew44 specialist can literally be powered by Copilot.

I built an adapter that lets Crew44 spawn Copilot CLI, read its structured output, normalize events into Crew44’s internal message model, and show a Copilot-backed turn the same way it shows turns from other runtimes.

That was a key finishing milestone. The runtime layer did not feel complete until Copilot was not a special case or side experiment, but a real teammate in the same crew system.

The goal was not to replace Copilot. It was to give Copilot a better seat at the table.

Sometimes I want Copilot to be the implementer. Sometimes I want it as a reviewer. Sometimes I want another model to plan and Copilot to handle a narrower coding pass. Crew44 makes that kind of role assignment explicit.

Copilot was especially helpful in the parts of the project where consistency mattered: normalizing runtime behavior, keeping the UI contract clean, and making sure the adapter fit the same shape as every other backend.

The Finish-Up-A-Thon prompt asks for a before and after, and Copilot was part of both.

Before, I was using Copilot as one more separate tool in the pile.

After, Copilot is one of the agents that Crew44 can coordinate inside a shared local workspace.

That feels like the right ending for this project: not “one AI tool to rule them all,” but a way to let the tools I already use work together.

---

Regardless of the challenge result, I’m just happy Crew44 made it out of my private toolbox and into the open.

If it helps even a few developers spend less time babysitting separate agents and more time building, that already feels like a win.

Thanks for reading — and good luck to everyone else finishing something they once left half-done.