In Juju, an agent is a jujud / containeragent process that works to realise the state declared by a Juju end-user with a Juju client (e.g., the Juju CLI) for a Juju entity (e.g., controller, model, machine, unit) via workers.
On machines, an agent is managed by systemd.
See more: Juju Dev | Agent
Contents:
Controller agent
On machine and Kubernetes clouds, a jujud process running workers responsible for a controller. This includes, among others, the apiserver worker, which is responsible for running the Juju API server.
Machine agent
On machine clouds, a jujud process running workers responsible for a machine.
Model agent
On machine and Kubernetes clouds, a jujud process running workers responsible for all the models associated with a given controller.
Unit agent
On machine / Kubernetes clouds, a jujud / containeragent process responsible for a unit.
When a Juju user uses the client (e.g., types a command in the CLI), this goes to the controller agent’s apiserver, which passes it on to the database. The database runs a background process that checks if anything has changed and, if so, emits an event (think “I’ve seen something that’s changed. Do you care about it?”). The event cascades through Juju. The unit agent becomes aware of it by always polling the controller agent as part of a reconciliation loop trying to reconcile the unit agent’s local state to the remote state on the controller (i.e., the state in the controller’s database).