Automation Design Portal

Problem

At Joblogic, every new third-party integration was a multi-day manual effort. An automation engineer had to hunt for the right API endpoints across sprawling documentation, read through related repositories to learn house conventions and which reusable utilities already existed, chase product for clarification on ambiguous requirements, and only then hand-write the implementation and its tests.

It was repetitive, easy to get subtly wrong, and bottlenecked on a handful of senior engineers. The integration backlog grew faster than the team could clear it — and most of the work wasn't creative, it was discovery.

My role

AI Engineer — I designed and built the system end to end: the LangGraph agent graph, the code-aware retrieval layer, the human-in-the-loop clarification flow, the PRD synthesis, and the handoff into Claude Code.

Approach & architecture

The portal reframes "build an integration with X" as a guided, AI-driven pipeline. The engineer describes the goal in natural language; a LangGraph agent then performs the discovery a human normally would — but in minutes, with every relevant convention already in context.

1. 1

   Intake

   The engineer describes the integration they need, in plain language.

2. 2

   Endpoint discovery

   The agent searches the API surface and docs to locate the relevant endpoints and contracts.

3. 3

   Codebase study — RAG over code

   It retrieves related repositories to learn the codebase's conventions and the reusable utilities it should build on.

4. 4

   Clarification loop

   Where requirements are ambiguous, the agent asks the engineer targeted, high-value questions.

5. 5

   PRD synthesis

   It produces a detailed, reviewable product + technical spec — the contract for the build.

6. 6

   Implementation handoff

   The approved PRD is handed to Claude Code (Opus 4.8) to generate the implementation and tests.

The defining principle is grounding over guessing. Rather than synthesising plausible-looking code from the model's priors, the agent retrieves the real endpoints and the real utilities, so what it specifies matches how the team actually builds.

Hard parts

• Reuse, not reinvention. RAG over a large code surface is only useful if ranking surfaces the right utilities. Tuning chunking and retrieval so the agent reused existing helpers — instead of quietly re-implementing them — was most of the engineering.
• Knowing when to ask. Too many clarifying questions and engineers abandon the flow; too few and the PRD is confidently wrong. The agent is tuned to ask only where ambiguity is load-bearing.
• The PRD as a contract. Making the intermediate artifact reviewable and editable keeps a human in control at the highest-leverage moment — before code exists.
• Determinism and recovery. Modelling the workflow as an explicit LangGraph state machine made retries, idempotency and partial-failure recovery tractable, rather than relying on a single fragile prompt.

Impact

• Collapsed a multi-step manual integration workflow into a single guided session — ‹defensible before→after, e.g. "days to hours"›.
• ‹defensible metric: integrations shipped / backlog cleared per quarter›.
• Shifted senior engineers off boilerplate and discovery; less-senior engineers can now drive integrations with the agent as a force multiplier.

This is agentic software engineering in practice: collapsing a multi-step manual workflow into a guided pipeline, with the human kept exactly where their judgement matters most.