Agentic AI Development

When a chatbot is not enough

A conversational interface is useful for answering a question. A task such as investigating a finding, retrieving supporting evidence and assembling a report also needs state, tool execution and a clear completion condition. Agentic workflows are a fit when those steps vary with the evidence available.

I work as an AI Engineer (SE) at CodingCops, where my experience includes DeepAgents, agent harnesses, LangGraph, Memgraph, Amazon DynamoDB and production deployment. The public examples below show related engineering work; they do not disclose private employer projects.

Inputs, outputs and scope

Inputs

A defined business task, allowed tools or APIs, example successful outcomes, access rules and representative failure cases.

Outputs

A stateful workflow, typed tool interfaces, an application API, run traces, evaluation cases and operating documentation.

Decisions to agree

Which actions need approval, how long a run may last, what is stored in memory and when the agent must stop or escalate.

Technical approach

1. Model the task before choosing agents

   Define the workflow state, completion criteria and boundaries. Use a fixed sequence for predictable steps; introduce agent decisions where the next useful action depends on retrieved information or tool results.

2. Build the execution harness

   Connect tools with validated inputs and explicit errors. Add timeouts, bounded retries, step limits and recovery paths. Record tool outcomes and state transitions so a failed run can be understood and resumed where appropriate.

3. Choose memory for the workload

   Use persistence for the state that must survive a run. Memgraph can represent connected entities; Amazon DynamoDB can store application records and agent state. The data model, access pattern and retention requirements determine which storage belongs in the design.

4. Evaluate before expanding autonomy

   Run representative tasks, missing-information cases and tool failures. Inspect successful completion, unsupported claims, action correctness, cost and latency. Add human review before consequential writes or external actions.

Delivery and evaluation

Delivery begins with one bounded workflow and an agreed set of examples. I would first establish the expected output and baseline, then build the tool and state layer, expose it through an application API and add deployment configuration and run monitoring.

The acceptance review uses complete task runs rather than a few attractive chat responses. A handover should explain tool permissions, retry behavior, state storage, release configuration and how an operator investigates a failed run. Performance targets are agreed for the actual workload rather than assumed from a demo.

Relevant public work

These project pages provide concrete examples of related engineering and identify prototype or research scope where applicable.

Questions about this service

Do I need a multi-agent architecture?

Only when separate responsibilities, tools or review paths justify it. A single workflow with explicit state is often easier to evaluate and maintain. The architecture follows the task rather than the number of agents.

Can you add agents to an existing application?

Yes. A useful starting point is one API-backed workflow with defined permissions and a small evaluation set. Existing authentication, storage and application behavior should inform the integration.

How will we know whether the workflow works?

We agree on representative tasks and completion criteria, then inspect outputs and execution traces. Measures can include task completion, correct tool use, recovery from failures, response time and cost.