IntegrationCodingAssistant

• 

  Architecture

• 

• 

Inspiration

Every Oracle Integration Cloud (OIC) integration starts the same way: before a single line of business logic exists, someone spends half an hour on the scaffolding — a trigger connection, a WSDL/JCA adapter pair, a tracking variable that has to match a payload field, a passthrough map, a project.xml with three separate XML namespaces, and a precise ZIP layout that OIC rejects if a directory name is off by one character. It's identical work every time, it's easy to get subtly wrong, and it's exactly the kind of thing that should be a short conversation, not a checklist.

We already had a generator that turns a YAML spec into a valid .iar / .car. What was missing was the part that decides what the spec should say — scheduled or application-driven? which pipeline role? what's the real tracking key? — and the part that gets the finished archive into an environment. Those are the pieces we built an agent around.

What it does

You describe the integration in a sentence. The agent:

1. Recalls conventions from a seedable file-backed memory — the code prefix, per-environment connection IDs, and a log of everything it has generated.
2. Picks the pattern. It classifies scheduled vs application-driven, chooses one of four standard templates, and looks up the recognised integration pattern it implements (Message Endpoint, Content-Based Router + Message Translator, Polling Consumer, …) along with its best-practice guardrails.
3. Proposes the whole spec — it does not interrogate. It derives the integration code as <DOMAIN>_<role suffix>, plus the operation, URI, tracking key and schedule frequency, and presents them. It only asks for what it genuinely can't infer — the payload fields, a downstream target's real URL.
4. Previews the spec as YAML and runs it past a spec_reviewer sub-agent that checks the naming, the tracking key, and the exact "Invoke <Target>" phrasing that lineage tools depend on.
5. Generates the archive — a real, CRC-valid .iar or .car, importable via the OIC Console or the REST API.
6. Deploys it — import_to_oic(archive, env) uploads it to a live OIC instance over the Integration REST API.

How we built it

• Google ADK 2 for the agent runtime, following the adk2 codelab's three pillars: deterministic work (spec validation, XML generation, the REST import) stays in plain Python tools — zero LLM cost, zero hallucinated XML — while the LLM owns the interview and the template choice. The reviewer is a collaborative sub-agent (AgentTool).
• Gemini 3.5 Flash via Vertex AI (AI Studio key for local dev).
• MCP via FastMCP — the nine tool functions are registered on an MCP server; the ADK agent and the server share one implementation. (ADK's own MCPToolset for the agent to consume MCP needs a newer mcp than we pin, so the agent calls the functions directly and the server re-exports them.)
• An industry-pattern reference (knowledge/integration_patterns.json) — curated from public sources only: the Enterprise Integration Patterns catalogue (Hohpe & Woolf), Oracle Integration's documented orchestration styles, and standard reliability guidance (retry/backoff, DLQ, idempotency, concurrency guards). Each template carries the pattern name and its guardrails; the agent folds them into every proposal.
• The OIC REST import — oic_import.py does OAuth2 client-credentials and posts the archive to /integrations/archive or /projects/archive. Connection config comes from environment variables or an existing OIC CD env.properties file — never from the repo — and a prod-looking environment is refused unless the operator sets OIC_ALLOW_PROD=1.
• Memory is a custom BaseMemoryService backed by a Markdown file you can open and read (adapted from the MonsterTix memory codelab), seeded with the team's naming conventions and the per-pattern OIC build recipes.
• Eval — an ADK evalset pinning the agent's tool trajectory, plus deterministic pytest for the builder, generator and import guards that needs no model at all.
• Two front doors in one container (the MonsterTix pattern) — a custom Studio chat page with a one-click archive download, plus ADK's /dev-ui.
• The archive generators are vendored from our OIC traceability tooling and re-packaged so the cross-module imports still resolve.

Challenges we ran into

• The .iar/.car format is very strict. Artifacts are managed by Vendor. Checks check sum for integrity of code archive.
• Getting the agent to propose instead of interrogate. Early versions asked "what code would you like for this integration?" — the exact boilerplate question a developer shouldn't have to answer. The fix was to give each template a code_suffix and OIC build_notes, and rewrite the instruction so the agent derives the code, operation, URI and frequency and presents the whole proposal up front.
• Keeping client data out. An earlier version of the pattern knowledge base scanned real integration archives. We replaced it with a hand-curated reference built entirely from public patterns — no proprietary shapes, connection ids, or payloads anywhere in the repo.
• Making the REST import safe by default. It reads credentials from the environment or an existing config file, never a committed one, and it refuses prod without an explicit opt-in.
• Eval determinism. LLM output varies, so the evalset leans on the tool trajectory and the hard correctness guarantees live in the model-free tests.

Accomplishments that we're proud of

• Developer inputs,Integration out. The agent goes from technical requirements to an integration artifact that can be imported through MCP Tools
• It proposes, it doesn't interview. For a typical request the developer answers one question — the payload fields — and everything else is derived and confirmed.
• Clean provenance. The pattern knowledge is public and cited; the deployment credentials are never in the repo.

What we learned

• Team went through resources and how GCS (Google Cloud Services) can be leveraged to build coding agents.
• Leverage Memory Bank/MCP Tools to be more context relevant
• How productivity can be increased and show proof of concept to leadership and product owners

What's next for IntegrationCodingAgent

• Agentic Capabilities — Enabling integrations as MCP tools and build AI Agents for major business functions
• Integration Patterns — Enable Order2Cash and Supply Chain Functions from ERP
• CI/CD process — build continuous loop with HIL(Human In Loop) for better performance.
• Updates — update integrations with new changes or enhancements.

Built With

• agent-development-kit
• cloud-run
• fastapi
• gemini-3.6-flash
• google-adk
• oauth2
• oic-rest-api
• oracle-integration-cloud
• python
• uvicorn