Most bad agent output isn’t too mysterious. Usually, the agent is missing the proper shape of your system.
Your Oracle AI Database work may be split into live schemas, distributed apps, views, grants, SQL dialect details, generated DDL, docs, and the few sentences in your head about what the app actually does.
In this article we’ll look at using agents intelligently to develop with Oracle AI Database.
Create and share agent skills
If you’re new to skills, they’re modules of instructions, scripts, and resources that describe how to execute specific tasks. Skills are (in general) more token-efficient than MCP tool calls.
Oracle maintains a repository of general-purpose Oracle AI Database skills. Downloading and installing these skills is a great starting point to enhance your coding agents with Oracle-specific knowledge.
I also highly recommend experimenting with skills to create and share your own implementations. Most of us have individual or business-specific use cases that can benefit from specialized knowledge.
Connect the agent to a database
If you’re working on software that interacts with a database schema, I recommend trying out the SQLcl MCP server.
MCP is useful because it standardizes how an AI application connects to external systems such as files, databases, tools, and workflows. The SQLcl MCP Server allows AI applications to interact with Oracle AI Database instances through named or saved SQLcl connections.
If you’re connecting MCP to an important or shared database, I recommend reading up on Oracle’s database security controls and best practices. In general, allowing agents access to real production databases should be tightly controlled.
Put intent in the database
Agents are better when the database carries more of its own explanation.
Oracle AI Database has two useful levels for this. The simple one is COMMENT ON. Comments are stored in the data dictionary for tables, columns, views, materialized views, property graphs, and other objects, and table or column comments can be read from views such as USER_TAB_COMMENTS and USER_COL_COMMENTS:
comment on table support_tickets is
'Customer support cases. Use status and sla_status for operational filters.';
comment on column support_tickets.payload is
'JSON diagnostics captured from the customer environment.';The structured option is the annotations clause. Annotations are centrally stored, shared application metadata. They can be added to database objects at create time or altered later, and dictionary views track their usage:
create table ticket_chunks (
chunk_id number generated always as identity primary key,
ticket_id number not null,
chunk_type varchar2(30) not null,
chunk_text clob not null,
embedding vector(384, FLOAT32)
annotations(
Distance 'COSINE',
IndexType 'IVF',
AgentUse 'rank support tickets and runbook chunks by semantic similarity'
)
);For broader business meaning, I would use comments for prose and annotations for compact, machine-readable hints.
Enrich context with primary and secondary developer resources
Chances are, the problem you’re attempting to solve is at least partially covered in the official Oracle AI Database documentation, or by an external resource like a blog post (if not, let me know, and we’ll work to get it covered!).
For example, if you’re working on adding property graphs to your app, don’t just say “add a property graph”. Link back to sections of the developer guide, or grab snippets from a blog post. Specific, clean, developer-friendly examples will go a long way to enhancing context.
For an agent, that context changes the task from: “Build a graph query for recommendations.”
to: “Use Oracle AI Database SQL property graph syntax from these docs, follow this sample’s CREATE PROPERTY GRAPH mapping, and write a GRAPH_TABLE query that preserves source and destination direction. Do not use PGQL unless we choose that route.”
We don’t want the agents to browse and create fully by vibes. Agents work best with directed, factual information and a clean spec. When I am working on a specific Oracle AI Database feature, I try to bring the relevant docs into context early.
Understand your coding assistant’s toolbox
I use /plan heavily because it is the cheapest place to spec out the work.
The first plan is rarely perfect, which is fine. These tools help the agent expose its assumptions before it edits code or runs a migration. With Oracle AI Database work, I especially look for small mistakes:
- wrong feature name or release assumption
- SQL syntax borrowed from another database
- missing grant or privilege
- invalid DML/DDL
- guessed table relationships
- generated tests that do not actually start Oracle AI Database Free
- links to invalid or generic docs instead of the exact feature page
The MCP spec’s prompt model is a useful mental model here. Prompts are structured messages and instructions that can be discovered and reused by clients. Your /plan habit is the interactive version of that: define the task, surface assumptions, correct them, then execute.
A loop I use
Here is the loop I would start with for serious Oracle AI Database coding-agent work:
- Save a SQLcl connection for a low-privilege schema and expose it through SQLcl MCP.
- Add comments and annotations for stable schema meaning.
- Put the exact Oracle docs or technical brief into context before asking for feature-specific code.
- Start in
/plan, then correct names, syntax, permissions, and test expectations. - Let the agent edit only after the plan is boringly specific.
- Run the smallest real verification: a SQL query, unit test, integration test, or container-backed sample.
The goal is not to make the agent smarter in the abstract. The goal is to make the next token less dependent on guesswork.
When the agent can inspect the schema, read the right docs, see your intent in comments and annotations, and work from a corrected plan, it stops feeling like autocomplete with ambition. It becomes a useful junior developer with a good terminal, a narrow permission set, and a checklist you actually trust.
Leave a Reply