My Flock: AI Agents That Keep Work Moving
We are a small team here at Cloudly Studio and our work for Engineering-Led Brands is mainly for industrial manufacturing clients. Alongside that work, we are expanding with two new services. As we prepare to roll them out fully, the question is not just how to make the work good. It is how to keep all the work around it moving.
Both services need their own websites and LinkedIn pages, with content that is managed and updated regularly. Cloudly Studio itself has not been getting enough new marketing content. Adding two services does not make that existing gap disappear. It gives me more places where the gap can grow.
Then comes business development. Good work needs a clear offer, a relevant audience and a reason to start a conversation. A website going live is not the end of that process. It is one of the places the process begins.
Our websites are not typical pages assembled from a few blocks. They run on sophisticated code, often with advanced animations and integrations with our 3D product viewers. A marketing idea can become a development task very quickly. I need a developer ready to help bring the direction to life, without losing the idea somewhere between a brief and an implementation.
Then there are presentation decks, proposals and correspondence. A useful conversation might need a tailored deck. A potential project might depend on a reply, a reference image or a contractor’s handover. None of those tasks looks enormous on its own. Together, they create a substantial workload around the client work we already do.
The pressure is not simply a shortage of words or designs. It is the number of connected things that need attention, and the fact that much of that attention comes back to me.
FROM ONE USEFUL INTEGRATION TO A TEAM
In my previous post on LinkedIn, I wrote about connecting Claude to Flowtly. For me, that integration was a success. It made the possibility of working with business information through a conversation feel useful rather than abstract.
It also prompted a bigger question. If that interaction could help with one part of the business, could I build a coordinated team around the rest?
Instead of simply adding more hands, I decided to give an AI finance agent responsibility for helping me with Flowtly and build a wider team of specialist agents. That became My Flock.
Margot is the finance agent. Romy handles marketing, Axel web work, Tijn technical review, Kian research, Kai growth, Cleo presentations and Eden correspondence. Jasper coordinates the work and checks it against the original request.
Those are responsibilities, not a claim that every action is already automated. Putting Margot in charge of helping with Flowtly does not mean giving an agent independent authority over the company’s finances. The earlier integration’s success is not evidence that an agent can autonomously change financial records or make payments.
The same applies across the team. They are AI agents, not human employees. Giving them names and roles makes responsibilities easier to discuss. It does not magically supply the tools, context or judgement needed to carry them out.
I started building with ChatGPT, then moved to Claude. ChatGPT helped build the foundations. My first impression after the switch was less recovery and more usable delivery. But the workflow changed too, including parallel sessions and clearer checks. That is my experience of building one system, not a controlled comparison of the models. I will return to that in the next article.
Here, the more important question is what this team is meant to help me do.
KEEPING THE NEXT STEP ATTACHED TO THE WORK
One practical example is our furniture-service pitch work. The project brings together a chair model that we fine-tune (expert human work), the viewer (which humans built for us) and the story we want to present. There is a lot of human work involved as well as technical and marketing work. Those pieces do not become ready at the same moment.
Yesterday, I reported that our potential client confirmed they have access to our viewer demo and that we were waiting for client feedback. The project record reflects that change. The next step is to share the feedback when it arrives, rather than keep treating access as the thing holding us up.
That is a small but useful outcome: the status catches up with reality. It is not evidence that the agents delivered the pitch, approved the model or tested the viewer. Those are separate questions.
A resolved access issue should stop consuming attention. Pending feedback should remain visible. And unresolved model or viewer checks should not quietly become “done” because another dependency was cleared.
This is the kind of follow-through I want. Not a system that creates more activity around a project, but one that helps distinguish what has changed from what still needs a decision or an input.
If I have a short window to look at the work, I should be able to see whether there is something useful for me to do now, or whether we are waiting for someone else.
LETTING SPECIALISTS WORK WITHOUT LOSING THE BRIEF
This article is another real use case. There are saved drafts and specialist review. The build record documents a live pass in which Romy saved a revised article and Jasper reviewed the document before returning a link. That is a completed editorial step: a document I could open, with a review attached to the work.
It is not the same as a published article. And my request for this revision shows why that distinction matters. The earlier draft focused too much on the system’s interface and delivery problems. I wanted more of the business behind it: the studio, the two services and the practical workload that led me to build the team.
That is a judgement I still need to make. An agent can produce a coherent draft and still miss what I most need it to say.
An agent can produce a coherent draft and still miss what I most need it to say.
The next handoff also has a specific purpose. Axel is handling the web-ready copy and paste previews. Editorial work should give him a clear working text, not start a second competing implementation process.
For this to work, each specialist needs more than a summary of the last message. They need the original brief, the latest working version, the changes already accepted and the questions still open.
Otherwise, every handoff risks becoming a fresh interpretation of the job.
Jasper’s role cannot stop at passing a request to someone else. Coordination has to keep hold of the outcome. What did I ask for? What exists now? What still needs to happen?
Review should be specific too. Fix the identified problem. Keep the parts that already work. Leave genuine unknowns visible rather than burying them under another paragraph. A longer document is not evidence of a better one.
HUMAN WORK IS PART OF THE SYSTEM
Cloudly Spaces makes another dependency clear. The site is live, but there is still work to do on its scroll transition and opening. The project record identifies our colleague’s current branch and handover as the next dependency, so the remaining work can be approached without overwriting what he has already done.
The useful state here is not “the agents are fixing the site”. It is a named dependency and a next step: get the current handover and remaining punch list before implementation.
I need help coordinating with human contractors, not a parallel AI process that ignores them. Their work needs to remain part of the picture. What is the current version? Who is working on it? What input is needed next? Which changes have actually been reviewed?
Getting that coordination right is still a goal, not something I can claim has been fully automated. A visible handover dependency is a start. It is not a completed handover or a repaired website.
That boundary is especially important when the marketing vision involves motion, interactive product content and code. A convincing description of an improved experience is not an implemented experience.
A convincing description of an improved experience is not an implemented experience.
THE DANGEROUS LITTLE WORD: DONE
A useful answer feels like progress. A confident answer can feel like completion. But a draft is not a saved document. A queued task is not a finished task. A saved document is not a delivered email. And none of those things means I have approved something for publication.
These distinctions matter because I am trying to run actual business work through the system. I want to ask for an article and get an article I can open. Not a promise that one will appear. Not a convincing description of what it would say.
Completion needs evidence at the point where I use the result. Is the requested change in the document? Is this the right version? Has the email actually been sent, or is it ready for me to review?
Access has its own boundary. Reading a website does not mean being able to update it. Knowing where a document lives does not mean having permission to share it. Useful tools are working already, while other execution paths are still being built or verified.
I do not want to flatten that into either “everything works” or “nothing works”. Both hide the information I need.
Building in public also does not mean putting the business in public. I can share these lessons without publishing client correspondence or sensitive financial records.
SPENDING MY ATTENTION WHERE IT MATTERS
The aim is not to fill every website and LinkedIn page with more content, or make a team of agents look busy. It is to connect the work so that something important is less likely to slip through the cracks.
Marketing needs to connect to the offer. The offer needs to connect to business development. A promising conversation may need a deck, a reply or a technical demonstration. A contractor may need a decision before the next piece can move.
Some of that is happening in small, verifiable steps. Much of the wider workflow is still what I want to build. I remain in control of the decisions and external actions. That does not mean I want to manage every internal handoff. It means I want to know where my judgement is needed, what evidence I am looking at and what will happen next if I approve it.
My limited time should go towards choosing a direction, checking the quality of an offer and dealing with the people involved. Less of it should disappear into remembering which thread contains the latest version or chasing a task that sounded finished but was not.
Clear ownership and honest status are not the mission on their own. They are what make useful delegation possible without losing control.
That is why I am building My Flock. Not because I need more answers, but because I need the work around those answers to move forward.
Not because I need more answers, but because I need the work around those answers to move forward.
In the next article, I will look more closely at building with ChatGPT and Claude: what changed in the tools, what changed in the workflow, and what I learned about getting useful work delivered.