Starting and Stopping Agents in Oracle AI Database 26ai

Question: is it still possible to start and stop remote Intelligent Agents in Oracle 26ai?

No. The classic Intelligent Agent, the SNMP-based component controlled through dbsnmp, agentctl, and lsnrctl dbsnmp_start back in the Oracle 8i/9i era, doesn't exist in Oracle AI Database 26ai. It was replaced years ago by the Oracle Management Agent used with Enterprise Manager, covered in the previous two lessons.

That leaves two genuinely different things you actually start, stop, or otherwise control today, worth keeping separate rather than treating as one topic:

Start, stop, or restart a Management Agent from the Enterprise Manager console (the agent's own homepage, then Control), or directly on the agent host with emctl start agent or emctl stop agent. Enterprise Manager 24ai added Remote Agents on top of this, letting a single agent monitor hosts and databases without a local agent installed on every target, covered in Module 3 Lesson 1.

Confirming the change actually took effect is worth doing as its own step rather than assuming it worked. From the agent's own home directory:

emctl status agent

reports whether the agent process is running, how long it's been up, and whether it's currently able to reach its OMS. A stopped agent shows as unreachable rather than simply absent from the list, which is the detail worth remembering when a target suddenly stops reporting data: the agent process itself may be fine, but a network or certificate issue between it and the OMS can produce the same symptom as the agent being down. Checking status directly on the host, rather than only from the console, is how you tell those two situations apart.

Select AI Agents, the newer in-database AI agent framework, covered in Module 3 Lesson 1's disambiguation, are enabled and disabled entirely differently, through the DBMS_CLOUD_AI_AGENT package rather than any Enterprise Manager mechanism:

DBMS_CLOUD_AI_AGENT.ENABLE_AGENT(agent_name => 'my_agent');
DBMS_CLOUD_AI_AGENT.DISABLE_AGENT(agent_name => 'my_agent');

That same package covers the rest of the framework an individual agent belongs to: CREATE_TASK and CREATE_TOOL for what an agent can actually do, and CREATE_TEAM/RUN_TEAM for running multiple agents together. Enabling or disabling one agent is a small piece of that larger picture, not a standalone switch. This support isn't exclusive to 26ai either, it's also available on Oracle Database 19c starting with version 19.29, worth knowing if you're working across mixed-version environments.

A fuller lifecycle makes the relationship between these calls clearer than ENABLE_AGENT/DISABLE_AGENT alone. Creating an agent, using it, and eventually retiring it looks roughly like:

DBMS_CLOUD_AI_AGENT.CREATE_AGENT(agent_name => 'my_agent', description => 'Customer order lookup agent');
DBMS_CLOUD_AI_AGENT.ENABLE_AGENT(agent_name => 'my_agent');
-- ... agent is available for use ...
DBMS_CLOUD_AI_AGENT.DISABLE_AGENT(agent_name => 'my_agent');
DBMS_CLOUD_AI_AGENT.DROP_AGENT(agent_name => 'my_agent');

Disabling an agent is reversible, a way to temporarily take it out of service without losing its configuration; dropping it is not, and removes the agent's definition entirely. That distinction matters operationally: if you're troubleshooting unexpected agent behavior, disabling first and only dropping once you're confident the definition itself is what needs to change is the safer order.

Older material describes starting the Intelligent Agent by first confirming no other SNMP components, master_peer, encap_peer, SNMPd, were already running, then launching them as root with start_peer -a from $ORACLE_HOME/network/SNMP/peer, before finally starting the agent itself with lsnrctl dbsnmp_start. None of that architecture exists in a current Oracle environment; there's no SNMP peer process to check for, and no dbsnmp_start command to run.

Worth understanding why that architecture existed in the first place, since the reasoning behind it is more durable than the specific commands: SNMP was originally chosen because it was a genuinely cross-platform, industry-standard protocol at a time when an Oracle database might be running on hardware, an IBM mainframe alongside a Unix server, for instance, that had little else in common with the Enterprise Manager console monitoring it. The peer-process model existed to bridge that gap. Once HTTPS became the universal transport, the entire premise of needing a specialized cross-platform monitoring protocol dissolved, every current platform speaks HTTPS natively, so there was nothing left for the SNMP bridge to actually solve.

If you're maintaining a genuinely ancient Oracle 8i or 9i system, that procedure remains historically accurate for that system specifically, but it has no bearing on 26ai, or on any Oracle release since roughly the early 2000s.

The next lesson looks at customizing Oracle alerts and how EM 24ai's incident rules replace what the old Event Manager handled manually.

Component	Era	Control mechanism
Intelligent Agent / SNMP peer processes	Oracle 8i/9i	Retired; start_peer -a and lsnrctl dbsnmp_start no longer exist
Oracle Management Agent	10g through current 24ai	emctl start/stop agent, or Control from the agent homepage in Enterprise Manager
Select AI Agent	19c (19.29+) and 26ai	DBMS_CLOUD_AI_AGENT.ENABLE_AGENT / DISABLE_AGENT, entirely inside the database

One row is retired history, and the other two are both current, but they're not interchangeable, and neither replaced the other. They solve different problems: one monitors infrastructure, the other runs AI reasoning inside the database itself. Knowing which one a given task actually needs is most of what this lesson set out to clarify.