I Tried Paperclip: My Engineering Team Worked. I Fired the Growth Team.
What I set up
Paperclip is an app for managing AI agents at work. I used it to put agents into teams, give them different roles, and organize how work moved between them.
I ran it on my home server and used Cloudflare to make it accessible over the internet for my Slack webhook setup. I wanted the team to notify me in Slack when it needed approval, so I didn't have to keep checking on it.
Without that incoming webhook requirement, I could have kept my setup local.
For engineering, I connected Jira, Confluence, GitHub, and Slack. The team started doing well once it had access to those tools. It could get to the tickets, the project documentation, the code, and me when it needed a decision.
I gave engineering work I'd already defined
I started with simple tasks, mostly picking up bug fixes from an already groomed backlog.
I'd already worked out what needed to be done. I wasn't asking the team to figure out the product direction or decide what was worth building.
The team had a manager that prioritized and assigned work, a coder using Codex, and a reviewer using Claude. Once a task was done, the manager knew to assign the next one.
I plan to grow this to two engineering teams eventually. For now, I'm keeping the tasks small while I see how the setup holds up.
A finished task still had to get through review
I already had unit tests, regression tests, and CI pipelines in place. The team had to run the tests and make sure the checks passed.
After implementation, the reviewer checked the work and signed off. It then went back to the manager, who sent it to me for final approval before the pull request could be merged.
So the process was fairly familiar:
- The manager picked and assigned a task.
- The coder made the change and ran the checks.
- The reviewer reviewed it and signed off.
- The manager brought it back to me.
- I gave the final approval before merge.
That setup worked well for the small tasks I gave it. I could open the ticket, look at the change, check the results, and decide whether I was happy with it.
The backlog and tests were already there before the agents arrived. I think that helped a lot. The team had something specific to work toward and a way to check its work.
Then there was the growth team
The growth team kept missing the mark.
It was running, but I wasn't getting useful direction out of it. Some of the things it wanted to do also ran into limitations. I kept looking at the output and finding that it wasn't what I needed.
Eventually, I shut the whole team down.
I still want to use agents to help with that work, but I'm changing what I ask them to do. My plan now is to build a team that handles specific coding tasks for a human marketing person. The person would own the marketing direction and give the agents technical work to carry out.
That's closer to what worked with engineering, so it's what I want to try next.
What I'm taking into the next attempt
The clearest difference for me was how easily I could judge the engineering work. There was a ticket, a code change, tests, and a review. I could tell whether the team had addressed the task I'd assigned.
With growth, I kept getting work that missed my expectations. I need to think more carefully about what I'm asking for and which decisions I want a person to keep making.
I'm happy enough with the engineering results to keep going. But these have been small tasks from a backlog I'd already prepared, with checks I'd already set up and my approval still required before merge.
That's the setup I'm building on for now. I'll keep giving the engineering team specific work, and I'll try a narrower role for agents supporting marketing. The growth team didn't work out, but it helped me decide what to try next.
Top comments (2)
The distinction between engineering tasks with defined tickets and less bounded growth work is useful. What approval boundaries or success criteria would you add before giving the growth team another attempt?
I’d start with smaller tasks under a human marketing lead, with a clear audience, deliverable, and definition of done. “Grow the product” leaves too much open.
Research and drafts could move ahead, but publishing, outreach, spending, or changes to messaging would need approval. I’d also have them bring back a proposed direction early so I can catch a mismatch before they spend more time on it.
For the next attempt, success would be producing work the marketing lead can actually use without having to redirect the whole task.