All articles

Getting Started

What is CICDoo Getting started: the onboarding wizard The Dashboard and Infrastructure Map

Concepts

Production, staging and development stages Domains, subdomains and SSL Odoo versions and editions (Community vs Enterprise) Workspaces and team collaboration

Servers

Adding a server Server domains and DNS Using a load balancer Server actions: deploy, logs and charts

Projects & Git

Creating a project Connecting GitHub Connecting GitLab Branches and instances

Instances & 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 queue

Agent Tasks

What agent tasks are Setting up agent tasks Running a task and reviewing the result Agent time and top-ups

Monitoring & 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 resource

Account & Security

Two-factor authentication (2FA) Profile and integrations settings Passwords and account recovery

Billing & Plans

Plans and pricing Upgrading and managing your subscription If a project subscription goes unpaid The channel partner program

Support & Tickets

Opening a support ticket Getting help from the CICDoo team

Troubleshooting

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 problems

Agent Tasks

What agent tasks are

Describe a change in plain language and a coding agent plans it, waits for your approval, then implements it inside the instance you picked. What the agent can and cannot do, and the rules that protect production.

What an agent task is

An agent task is a piece of work you describe in plain language. A coding agent picks it up inside one of your own instances, works out how to do it, and waits for you to approve that plan before it writes any code. Once you approve, it implements the change in that instance and pushes the result to the instance's branch.

You are not handing work to a service somewhere else. The agent runs in your instance's container, against your code, on the branch that instance is deployed from.

The three steps

Every task moves through the same three steps, and you are in the middle of them.

  1. You describe the work. A title and a description of what should change. Plain language is enough; you do not write instructions for a machine. You pick which instance the agent works in, and you can attach files for context.
  2. The agent plans. It reads the codebase in that instance and writes back a plan: what it intends to change and how. Nothing is written yet. If the ask is unclear or it cannot do the work safely, it says so instead of guessing, and the task waits for you.
  3. You approve, then it implements. Once you approve the plan, the agent makes the change, commits it and pushes to the instance's branch. That push redeploys the instance, so you can look at the result running.

If the result is not what you wanted, you send it back for another round. The agent builds on the code it already pushed rather than starting over, and you approve the new plan before anything runs again.

Where an agent can work

Agent tasks run on the instances of a project you have enabled them for. Staging and development instances are the normal place for this work: a poller runs inside each of them, ready to pick tasks up.

Production is allowed, but deliberately awkward. A task aimed at a production instance has to be confirmed when you create it, and its plan always waits for a person to read it. Auto-execute, which lets a plan run without review, is refused outright on production. There is no combination of settings that lets an agent change production while nobody is watching.

What the agent produces is yours to check

The agent writes generated code. It can be wrong, or incomplete, in ways that are not obvious from reading the plan. Treat its output the way you would treat a pull request from someone who has never seen your business:

  • Take a current backup before approving anything on production.
  • Have someone who knows the codebase read the plan, not just the summary.
  • Test the result on the instance before you carry it forward.

CICDoo provides the agent as a tool. The changes that get made are the ones you approved, and the outcome of those changes is yours. This is set out in section 11 of the Terms of Service.

What it is not

  • Not a chatbot. It does not answer questions about your data; it changes code in an instance.
  • Not the AI log analysis feature. That is a separate thing, for reading deploy and server logs.
  • Not a shared service. The agent runs on your own provider account, using a credential you supply, so runs count against your own subscription or quota with that provider.

Next steps

To switch it on, see Setting up agent tasks. For running a task and reviewing what came back, see Running a task and reviewing the result. For how agent time is measured and topped up, see Agent time and top-ups.

If you get stuck, open a support ticket from the Tickets page or the chat widget.

Previous Passwords and account recovery Next Setting up agent tasks

Still stuck? Open a ticket from the app or talk to an engineer.