All articles
Getting Started
What is CICDoo Getting started: the onboarding wizard The Dashboard and Infrastructure MapConcepts
Production, staging and development stages Domains, subdomains and SSL Odoo versions and editions (Community vs Enterprise) Workspaces and team collaborationServers
Adding a server Server domains and DNS Using a load balancer Server actions: deploy, logs and chartsProjects & Git
Creating a project Connecting GitHub Connecting GitLab Branches and instancesInstances & Console
Creating an instance Restarting, stopping and removing an instance Merging branches between stages Web IDE and remote access Instance settings explained Deployments and the job queueAgent Tasks
What agent tasks are Setting up agent tasks Running a task and reviewing the result Agent time and top-upsMonitoring & Backups
Monitoring your instance Backups and restore Alert notifications (email and SMS)Workspaces & Permissions
Inviting workspace members Member permissions and resource access A member cannot see or use a resourceAccount & Security
Two-factor authentication (2FA) Profile and integrations settings Passwords and account recoveryBilling & Plans
Plans and pricing Upgrading and managing your subscription If a project subscription goes unpaid The channel partner programSupport & Tickets
Opening a support ticket Getting help from the CICDoo teamTroubleshooting
Troubleshooting: cannot connect a server Troubleshooting: a deployment failed Troubleshooting: git push fails with 403 after moving a repository Troubleshooting: my instance is down or slow Troubleshooting: domain or SSL problemsAgent Tasks
Running a task and reviewing the result
Creating an agent task, reading and approving the plan, what lands in git, sending work back for another round, and what happens when a run fails or hits a provider limit.
Creating a task
Open a project's Tasks page, or the Tasks tab of an instance console, and create one. You give it:
- A title and a description. What should change, in plain language. Detail helps: the same ask with two sentences of context produces a much better plan than the ask alone.
- The instance to work in. This decides which codebase the agent reads and which branch the result is pushed to.
- Skills and attachments, optionally. Skills are your house conventions; attachments are files the agent should have for context, such as a spec or a screenshot of the problem.
Creating tasks needs the agent-tasks permission. If the project's subscription is unpaid and the project has gone read-only, task creation is refused along with every other action.
Targeting the production instance requires you to type confirm when you
create the task, and the task is recorded as a production task from then on.
Reading the plan
The agent picks the task up, reads the codebase and writes back a plan. Nothing has been changed yet at this point.
Read the plan itself, not just its first line. It is your only chance to catch a misunderstanding before code is written, and the cost of reading it is far lower than the cost of unpicking a bad change afterwards.
Then choose:
- Approve & Execute — the agent implements the plan.
- Request Changes — describe what is wrong and it plans again, with your feedback in hand.
- Plan Again — reruns planning as-is, useful when the first attempt failed rather than went wrong. Plan Again With Guidance does the same with a note from you.
- Cancel Task — stops it.
Approving needs the plan-approval permission.
Sometimes the agent reports the plan as blocked: it has decided it cannot do the work safely or the ask is not clear enough. A blocked plan always waits for a person, even on a project with auto-execute switched on.
What lands in git
Once you approve, the agent makes the change inside the instance's container, commits it, and pushes to that instance's branch. That push redeploys the instance, so the result is running where you can look at it.
There is no pull request. The commit goes straight onto the branch the instance is deployed from, which is why the instance you pick matters and why production is fenced off behind two confirmations.
If the run finishes without needing to change anything, it says so rather than inventing a commit.
When the result is not right
Use Start Another Round on the task. Describe what is wrong and the agent plans a fix, building on the code it already pushed rather than starting over. You approve the new plan before anything runs, and the existing commit stays on the branch.
Rounds are counted on the task, so you can see how many passes a piece of work took and what each one changed.
When something goes wrong
- The instance will not start with what the run committed. CICDoo moves those commits onto a rescue branch, resets the instance's branch, and brings Odoo back up. Nothing is pushed and nothing is lost: the work is on the rescue branch if you want it.
- The push fails. The work stays in the container's working tree rather than disappearing.
- The run hits your provider's usage limit. The task pauses and tells you when the limit resets. Resume carries on with the approved plan from that point; it is the same round, interrupted, not a new one.
- The run stops reporting. If a container dies mid-work, the task is marked failed rather than left hanging forever. If the agent reports in late after that, the result is still picked up.
Watching usage
The task's Usage tab lists every run behind it: which round and phase, who
triggered it, the outcome, tokens in and out, and the time it took. The /agent
page rolls this up across projects, with charts over the last 30 days, 90 days or
12 months.
Retries and failures are counted too. That is deliberate: they cost real agent time, and a task that took four attempts should look like it did.
Next steps
For how that time is measured and paid for, see Agent time and top-ups. For enabling the feature and connecting a CLI, see Setting up agent tasks.
If you get stuck, open a support ticket from the Tickets page or the chat widget.
Still stuck? Open a ticket from the app or talk to an engineer.