The agent management console is the operational home base for every AI agent your organization runs. It brings registration, configuration, version control, attestation, and live debugging into a single organization-scoped interface so your team can govern the entire agent fleet without switching between tools. Each action is permission-gated, each change is versioned, and every agent remains traceable back to the operator who created or last modified it. For the identity mechanics that underpin every agent registered here, see how to give an AI agent its own identity.
Registering an Agent
Adding an agent to your fleet starts with the agent list at the core of the console. You create an agent by supplying its name, capabilities, and the deployment mode — direct push or polled routing, depending on how your infrastructure connects to Praesidia. The platform generates a unique agent identity, a client secret, and, if A2A communication is enabled, a private endpoint URL and an initial agent card.
Creation is permission-gated. Operators without the agent creation permission see the create button locked — they can browse the list and inspect existing agents, but they cannot add new ones. This separation keeps fleet growth deliberate: only operators who have been explicitly granted that permission can expand the agent roster.
Once created, the agent appears in the paginated agent table, scoped to your organization. The table shows status, deployment mode, last activity, and a trust score summary, giving you a quick pulse on the fleet before you drill into any individual agent.
Configuring and Updating Agents
The agent detail view is where configuration lives. You can update the agent's display name, description, and capabilities without recreating it. Changing an agent's status — activating, deactivating, or marking it as maintenance — propagates in real time to any workflow or connection that references it.
Two operations warrant particular care. Regenerating the client secret immediately invalidates the old one: any deployment still using the previous secret will fail to authenticate until it picks up the new value. Secret rotation is intentional and audited — the console records who triggered the rotation and when. The same applies to the webhook signing secret, which governs how the agent verifies inbound task payloads.
Cloning an agent is available for cases where you want a new agent that inherits the configuration of an existing one. The clone creates a fresh identity and secret; it does not inherit the source agent's active connections or version history, keeping the clone's lineage clean.
Version History and Rollback
Every configuration save creates a versioned snapshot. The versions panel for an agent shows the full history: who created each version, what changed, and a diff view that lets you compare any two versions side by side.
Rollback is a first-class operation. If a configuration change degrades an agent's behavior — a capability scope that is too narrow, a webhook URL that points to the wrong environment — you can select an earlier version and restore it. The rollback creates a new version record rather than silently overwriting, so the history remains complete and you can see that a rollback occurred and who performed it. For a broader look at versioning strategies across your agent fleet, see versioning and rollback for AI agents.
Prompt versioning works alongside configuration versioning. Separate from the agent's structural configuration, prompt versions capture the exact instruction text used at each point in time. You can activate a specific prompt version, compare two candidates, and roll back independently of the broader configuration. This is useful for teams that iterate frequently on prompts and need to bisect a behavioral change without rebuilding the entire agent.
Attestations: Cryptographic Claims About Your Agents
The attestations panel records externally verifiable claims about an agent's properties: its model version, its training lineage, its compliance posture, or any other fact an operator chooses to assert. Attestations are cryptographically signed so they can be independently verified later.
You can create an attestation with a structured payload that describes the claim, then verify it at any point to confirm the signature still holds. If an agent's properties change and an existing attestation no longer accurately reflects reality, you can revoke it and issue a new one. The full attestation history — creation, verification attempts, and revocations — is retained, giving auditors a clear record of what was claimed about an agent and when.
Attestations feed into the trust score that the platform computes for each agent. An agent with current, verified attestations scores higher than one with no claims or with revoked attestations. That score is visible from the agent detail and is accessible programmatically for teams that want to gate dispatch decisions on trust levels. For more on how trust scores inform authorization decisions, see trust scores and attestations: deciding which agents to trust.
The Debug Console
The debug console is an interactive execution panel built directly into the agent detail view. You select the agent, submit a task description, and the console routes the task through the same execution path that production traffic uses. As the task runs, a live trace viewer renders the execution steps — tool calls, intermediate outputs, and the final result — so you can see exactly what the agent did and in what order.
This is valuable for two scenarios. When you are first registering an agent and want to confirm the end-to-end connection is working, the debug console gives you an immediate, low-friction test without writing a script or constructing an API call manually. When an agent is misbehaving in production, you can reproduce the problematic input in the debug console and step through the trace to find where the execution diverged from expectations.
The trace output includes timing information for each step, which is useful for identifying performance bottlenecks in agents that call multiple tools or make several downstream requests before producing a result.
Collaborators and Access Control
Agents support collaborator relationships. You can add other members of your organization as collaborators on a specific agent, granting them visibility or management access without giving them broad permissions across the entire fleet. Collaborators are managed from the agent detail and the full collaborator list is visible to any operator with read access to that agent.
This per-agent access model is useful for organizations with specialized teams. A team responsible for a particular domain agent can manage it directly without needing elevated permissions on unrelated agents. The console enforces these boundaries: actions that exceed a user's effective permission on a given agent are rejected, and the UI reflects what is and is not available to the current user.
Common questions
Can I recover an agent after deleting it?
Deletion is permanent. The agent's identity, configuration, and connections are removed. Version history and audit records are retained for compliance purposes, but the agent cannot be restored. If there is any chance you will need the configuration again, create a version snapshot before deleting, or clone the agent and deactivate the original instead.
What is the difference between deactivating an agent and disabling A2A communication for it?
Deactivating an agent changes its status so it no longer accepts new tasks through the standard dispatch path. Disabling A2A communication specifically removes the agent from the inter-agent call graph: its endpoint is taken offline and all connections targeting it are marked disconnected. You can deactivate an agent while leaving A2A communication enabled, or disable A2A while leaving the agent active for direct task submission. The two controls are independent.
How does the trust score shown in the console relate to dispatch decisions?
The trust score aggregates signals — attestation coverage, behavioral history, and configuration completeness — into a numeric value that reflects how much confidence the platform has in the agent. The score is visible in the agent detail and accessible through the API. Your workflows and connection policies can reference the score to gate which agents are permitted to run sensitive tasks. See the platform documentation for details on configuring trust-based dispatch gates.
The agent management console gives your team a single, governed place to manage the full lifecycle of every AI agent in the organization. Praesidia is designed so that no agent enters production without an identity, no configuration change goes unversioned, and no execution happens without a trace — from initial registration through active operation and eventual decommission.