> For the complete documentation index, see [llms.txt](https://alludium.gitbook.io/alludium-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alludium.gitbook.io/alludium-docs/administration/2.-agents/2.2-agent-lifecycle.md). # Agent Lifecycle Agents move through two states: **In Development** — The agent is being built and configured in Agent Builder. Visible only to the creator. **Deployed** — Finalized and operational. Accessible to users in My Agents, available for manual invocation. Deployable agents can also be shared across the workspace. Agents do not become deployed without explicit action. Lifecycle is deliberate. *** ### My Agents: What You See by Default My Agents show **Deployed** agents only. If you cannot find an agent you recently created, check the agent in Agent Builder to ensure it has been deployed. *** ### The Two States Explained #### In Development **What it means:** The agent exists in Agent Builder and is being configured. System instructions are being written, tools are being selected, files are being linked, behaviour is being tested, and the configuration is being validated. **What you can do:** * Edit all configuration parameters * Add or remove tools * Link or unlink files * Modify system instructions * Change model settings * Test the agent via the test drawer (development chats remain here and are not visible in production) * Use the **Configure button** in the test panel to quickly review or adjust connections and prepare for deployment * Save configuration without deploying * Iterate on behaviour based on test results **What you cannot do:** * Access the agent in My Agents * Share the agent with other workspace members for production use **Who can see it:** Only you. Development agents are private to the creator until deployed. **Development Notifications:** If you have configured Notifications during development, be aware that these will fire in the development context. Best practice is to disable development Notifications before deploying to avoid unintended Notifications during configuration. When you deploy, review whether existing development Notifications should remain active. **Best practices:** * Test thoroughly in the test drawer before deploying * Run at least 3–5 sample tasks to validate behaviour * Test with diverse inputs to ensure consistency * Check that tool access is appropriate (not over-provisioned) * Verify linked files are correct and current * Document the agent's purpose clearly in the description * Get team review for shared agents before deployment **Validation checklist before deploying:** * \[ ] System instructions clearly define scope * \[ ] All required tools are connected and working * \[ ] Files contain current, accurate information * \[ ] Test outputs meet quality standards * \[ ] Agent description is accurate and helpful * \[ ] Expected inputs and outputs are documented * \[ ] You've tested edge cases and failure scenarios *** #### Deployed **What it means:** The agent is deployed and operational. It appears in My Agents for authorised users, maintains conversation history, can be invoked for production work, and can be scheduled to run automatically via automations. Deployed agents can be shared across the workspace. **What you can do:** * Invoke the agent in My Agents for on-demand tasks * Run production tasks with real data * Review and iterate on outputs in conversation * Maintain conversation history across sessions * Create time-based automations for scheduled execution * Configure automated notifications * Monitor usage patterns and performance * Collect feedback from users * Edit configuration (requires redeployment) * View usage metrics and analytics * Share the agent with workspace members **Who can see it:** Users with the appropriate role permissions and workspace access. Where My Agents is available to that user, the agent appears in their My Agents list. *** ### Automations and Notifications Automations and notifications are related but distinct. Every automation run generates a notification, but notifications can be independently enabled or disabled per environment (In Development and Deployed) and per user. This means you can have an automation active without receiving notifications for it, or silence notifications in one environment while keeping them on in another. *** #### Automations Automations define when an agent runs automatically on a scheduled date and time. **Automations carry over on deployment** Automations configured in your Development instance carry over to the Deployed environment when you deploy the agent. This means any automations you have set up and active during development will be live in production from the moment you deploy. Review automation configuration carefully before deploying and ensure you are comfortable with it running in a production context. **Automations are on by default for shared agents** When a builder deploys and shares an agent, any automations included in the shared configuration are enabled by default for all shared users. Each user can enable or disable individual automations from their own My Agents view. This only affects their own instance and does not change the builder's configuration or other users' settings. **Agent Configurator automation settings affect all shared users** When a builder modifies automation settings via the Agent Configurator, this updates the automation configuration for all shared users, not just the builder's own instance. If you need to adjust shared users' automation settings centrally, this is done through the Agent Configurator. Use this carefully and communicate changes to your team before making them. **Managing automations individually** Any user can manage their own automations directly from My Agents by navigating to the relevant agent and accessing its automation settings. Enabling or disabling an automation here only affects your own instance. **When to create automations** Best practice is to wait until the agent has proven itself through manual use before enabling scheduled automations: * Quality is consistent and validated * Workflow is stable and predictable * Users trust the agent's outputs *** #### Notifications Every time an automation runs, it generates a notification. Notifications can be turned on or off independently for each environment, so you can suppress notifications from Development automations while keeping them active for your Deployed instance, or vice versa. **Available notification channels:** * **Web** — In-platform notifications * **Email** — Notifications sent to the user's registered email * **Push** — Mobile push notifications (where applicable) Notification preferences are configured per user, per agent, and per environment. When a shared user first accesses an agent that requires setup, they are guided through a configuration screen where they can set their notification preferences alongside connections and automation settings. This only needs to be done once and can be updated at any time from within the agent in My Agents. Builders should communicate to their teams which notification channels are recommended for a given agent, particularly for time-sensitive automated workflows. *** ### Workspace Agent Sharing Once an agent is deployed, builders can share it with the workspace via the Share function. Sharing makes the agent available in every workspace member's My Agents. **How sharing works:** Shared users receive their own configurable instance of the agent. The original builder retains full control over the base configuration, system instructions, and integrations. Shared users can configure their own personal settings but cannot modify the agent itself. When sharing, builders choose: * Whether connections are **shared** (all users reuse one connection) or **user-configured** (each user connects their own account, e.g. their own Gmail) * Which automations to share, which users can then enable or disable individually * The initial notification and configuration behaviour for new users When a shared user first accesses the agent and setup is required, they are guided through a configuration screen to connect their accounts, enable or disable automations, and set notification preferences before use. *** ### State Transition: In Development To Deployed **What starts it:** You click **Deploy** in Agent Builder. **What happens:** * Agent configuration is validated and saved * Agent becomes visible in My Agents (under Deployed view) * Workspace members with access can invoke it * Conversation history begins tracking * Usage metrics start collecting * Agent appears in workspace dashboards **Pre-deployment checklist:** * \[ ] Configuration is validated and tested * \[ ] Team members know the agent is available (if being shared) * \[ ] Documentation is prepared * \[ ] Feedback collection method is ready * \[ ] Automation and notification settings have been reviewed * \[ ] You're ready to monitor initial usage **Rollback option:** You can edit the agent at any time. Click **Deploy** again to push the updated configuration live. *** ### State Indicators Agents display their current state in multiple locations: **In Agent Builder:** * State badge next to agent name (In Development or Deployed) * Last modified timestamp * Deployment status indicator **In My Agents:** * Defaults to Deployed agents only * Switch dropdown to **In Development** to see unpublished agents * Automation schedule shown if configured * Last invocation timestamp * Conversation history available **In workspace views:** * Agent lists show deployed agents * Agent detail views show current state * Setup indicators show whether configuration is required *** ### Editing Deployed Agents When you need to modify an agent that is already deployed: **Process:** 1. Navigate to Agent Builder and find the agent 2. Click **Edit** 3. Make configuration changes 4. Test changes in the test drawer 5. Click **Deploy** to push changes live **What's preserved:** * Existing conversation history remains intact * Automations continue on their schedule * Usage metrics and analytics history **What changes:** * Agent behaviour updates according to new configuration * System instructions take effect immediately * Tool access changes apply to new invocations **Note on automation settings:** If you update automation configuration via the Agent Configurator, this will affect the automation settings for all shared users. Communicate material changes to your team before deploying. **Best practices:** * Test changes thoroughly before redeployment * Notify users of significant behavioural changes * Monitor the first few post-update invocations * Keep edits focused — one change at a time makes debugging easier *** ### Lifecycle Best Practices Summary **In Development:** * Test extensively before deploying (minimum 3–5 diverse scenarios) * Start with templates when possible to accelerate configuration * Validate with edge cases and unusual inputs * Verify tool connections are working properly * Disable development automations before deploying to avoid unintended executions **Deployed:** * Monitor invocations closely in the early stages * Collect systematic feedback from all users * Document common refinements and patterns * Wait for proven quality before creating automations * Review automated outputs regularly if automations are configured * Update documentation as agent behaviour evolves * Remind users that they can manage their own automation and notification settings from My Agents **When Editing:** * Test changes thoroughly before redeployment * Document what changed and why * Be aware that Agent Configurator automation changes affect all shared users * Monitor closely after updates * Keep changes focused and incremental *** Next Steps: Now that you understand the agent lifecycle, continue to **Agent Types** to learn about the different categories of agents and when to use each type for specific workflows. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://alludium.gitbook.io/alludium-docs/administration/2.-agents/2.2-agent-lifecycle.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.