We run most of Codepixel through ClickUp.
Client delivery is there. Marketing is there. Business development is there. Strategic goals are there. Our SOPs are there. Even individual training and development plans are there.
More recently, we've connected an AI agent directly to that workspace. It can read the information inside it, create tasks and update existing work. This has removed a fair amount of operational admin.
The more interesting part is what needs to be in place before you can trust an agent to create a task at all.
The board has to reflect how the company works
We've used ClickUp for years, and our setup has evolved with the company.
Internally, we have one company space covering the work required to run Codepixel: business, marketing, administration and process standardisation. Delivery is separate.
Our client projects follow a consistent structure. A typical project has Design, Development and QA/Testing lists, with Client feedback, Internal feedback, Support or Migration added where the work requires them. Project briefs, database schemas and development documentation live inside the same project folder.
Larger product engagements need more structure. They get their own space, with a backlog separated into Major features, Improvements, Bugs, User feedback and Ideas. Work then moves into two-week sprints.
Client UAT has its own list. Warranty and post-launch bugs have another.
That last separation matters. A bug discovered after launch shouldn't quietly become part of the next batch of product development, and a new request shouldn't quietly become a warranty fix. The board makes that distinction visible.
We deliberately keep custom fields to a minimum. Spaces, lists and statuses carry most of the meaning.
The result isn't particularly clever. Someone joining a project can usually understand where things belong because every project follows the same logic.
Statuses are part of the process
A sprint task at Codepixel doesn't go directly from "in progress" to "complete". Our sprint flow is:
to do → in progress → dev completed → ready for testing → in testing → need repair → completed
Development being finished and work being tested are two different things.
That sounds obvious, but the distinction matters operationally. A developer saying something is done doesn't mean it is ready to close. QA has its own stage, its own responsibility and a visible place on the board.
The same thinking applies elsewhere. Business boards have a backlog for ideas that aren't active yet. Strategic work can move to "to review" before it is closed. Business development is separate from our sales pipeline because they are different processes.
Our CRM tells us what is happening with a deal. ClickUp tells us what work needs to happen. Trying to make one board do both would make both less useful.
Our strategy lives there too
We didn't want company strategy to exist in a presentation we open twice a year.
Each quarter has a parent task for implementing that quarter's strategic goals. Under it sit the actual goals across commercial work, marketing, operations and AI adoption. We review the board at the end of the quarter.
Our own adoption of AI was managed this way.
We started by researching agentic workflows. Then we introduced AI into parts of sales and operations. We documented our AI policy and the tools we could use. We worked on AI-assisted sales processes. Then we pushed further into delivery, including how smaller senior teams can handle short projects with AI supporting the work.
Each step was work on a board.
That matters because "use more AI" isn't an operational goal. Someone needs to decide where it belongs, what needs to change, who owns the change and when it is ready for actual use.
Then we gave an agent access to the work
Once the underlying structure was consistent enough, connecting an AI agent became much more useful.
We use Claude with its ClickUp connector. It can work directly with the information already inside our workspace.
One example came during the launch of our new website. We already had a campaign plan and comments from the team. Instead of manually translating that plan into a project board, we gave the material to the agent.
It created around 20 dated tasks in one pass.
Launch-day posts were separated by channel. The newsletter had its own task. Team activation was planned. Perspective posts were assigned to different people across the following week. PR work and planned content series became tasks too.
Each had an owner, priority, due date and enough context to explain what needed to happen. A plan became executable work in minutes.
The agent didn't decide what our launch strategy should be. We'd already done that work. It handled the administrative step of turning the decisions into a board the team could execute.
That's where we find AI much more useful.
A task should contain enough context to start working
We've applied the same idea to specifications.
A lot of Codepixel's company knowledge is stored in structured markdown files: services, industries, technologies, case studies and other material we use repeatedly. The agent can use that knowledge when preparing a task.
If we're creating a new website page, for example, the task can contain the page structure, proposed sections, source material and a reference to the related design task. The person picking it up doesn't have to start by asking where the brief is, which case study is relevant or what another task was supposed to cover.
This is useful for content too. Case studies and Insights articles move through our Marketing lists. AI can help prepare material inside the task. A person edits it, challenges weak claims and approves what gets published.
This article went through that process.
AI handles more of the preparation. People still own the decision.
What this changes for us day to day
We're a compact team running more than a dozen client projects in parallel. The board needs to answer a basic question quickly:
Where is this?
Where is the latest feedback? Where is the bug? Has QA seen it? Is the client testing it? Who owns the next action? Is this new scope or a warranty issue?
Consistent project structures make those questions easier to answer. Putting AI on top reduces another layer of work.
As CEO, my role touches sales, finance, operations and project management. Writing tasks, turning plans into action items, preparing briefs and following up on work used to take roughly 10-15 hours a week. Some of that work can now be prepared by an agent.
Handoffs are faster because tasks arrive with more context. Onboarding is easier because projects use the same structure. QA and client UAT have defined places in the process. Strategic work stays visible alongside operational work instead of disappearing into a document.
None of this removes the need to manage the company. It removes some of the mechanics around managing it.
AI on a messy board gives you more mess
This is the part that is easy to skip.
Connecting an AI agent to ClickUp didn't suddenly make our operation structured. The structure had to exist first.
If every project uses different statuses, people name tasks however they want, documentation is missing and nobody agrees on where work belongs, an agent has the same problem a new employee would have. It doesn't know what "done" means because the company hasn't defined it.
It can create 50 tasks faster than you can create five. That's not necessarily an improvement.
We're still standardising our own processes. Some of the ways we work developed through practice long before anyone wrote an SOP for them. We're going through those processes now and documenting what should be consistent.
The agent makes that gap more visible. If we can't explain a workflow clearly enough for the system to work with it, we probably haven't defined the workflow clearly enough ourselves.
We applied our own AI advice internally
We recently wrote about why companies should understand a process before implementing AI. This is the same principle applied to Codepixel.
We didn't begin with "How do we put an AI agent into ClickUp?"
We already had a system for running projects. We had statuses with specific meanings. We had project templates. We had written knowledge. We had clear separation between development, testing, client UAT and post-launch work.
That gave the agent something useful to work with. The technology came second.
For SMEs looking at agentic workflows, we think this distinction matters. Before choosing an agent, map the work you expect it to handle.
What information does it need? Where does that information live? Which actions can it take? Which decisions stay with a person? What does a completed task mean? What happens when the process doesn't follow the normal path?
Those are process questions before they're AI questions.
What this means for our clients
The same operating discipline sits behind the projects we run for clients.
There is a defined place for design, development, QA, feedback and post-launch work. Documentation sits next to delivery. Tasks move through explicit states. People remain responsible for what ships.
AI helps us prepare, structure and keep parts of that system current. It doesn't replace ownership.
We can also help companies apply the same thinking to their own operations: map an existing workflow, remove unnecessary steps, define the system around it and identify where AI or automation can take over useful work.
Bring us the process. We'll work out where AI belongs.
Was this useful?
