Multi-agent system
IC at GenpactAgentic Tool Builder
Designed as a LangChain-based multi-agent workspace where planning, execution, and validation are modeled as explicit responsibilities instead of being buried in one opaque loop.
Built as an individual contributor at Genpact using LangChain, focused on agent orchestration, tool execution, and validation flow.
System flow
Agentic Tool Builder architecture
A LangChain-driven workflow where the master orchestrator coordinates planning, approval, coding, sandboxed testing, retry loops, documentation, and final delivery.
Tap a handoff to inspect that part of the flow.
Current handoff
IntakeUser request to Master orchestrator
Overview
What this system does
Agentic Tool Builder is a LangChain-based agent harness for turning a user task into a controlled execution workflow. The system separates planning, orchestration, tool execution, validation, and final response handling so the behavior is easier to inspect.
The main idea was to avoid one opaque agent loop. Instead, the workflow makes each handoff explicit: what was planned, what was approved, what tool path was used, what validation found, and whether the task should retry or complete.
Contribution
My role in the build
The parts of the system where my ownership and design work mattered most.
Built as an individual contributor, with ownership around the LangChain orchestration flow and how specialist responsibilities were separated.
Designed the planner, executor, validator, and approval handoffs so agent behavior stayed visible instead of being buried inside a single prompt.
Focused on tool execution paths, retry behavior, trace visibility, and the control points needed to make the harness feel reliable.
Architecture decisions
Design choices that made the system easier to reason about
Decision 01
Separate planning from execution
The planner produces structure and intent, while the executor handles action. This prevents the same agent from deciding, acting, and validating itself.
Decision 02
Keep orchestration state explicit
Approval state, selected tools, intermediate outputs, and validation status are treated as workflow state rather than hidden prompt context.
Decision 03
Constrain tool pathways
Tool use is routed through narrower pathways so execution is easier to audit and less dependent on free-form model behavior.
Decision 04
Validate before release
The validator is part of the main flow, not a postscript. Failed validation routes back into execution with a correction path.
Reliability
How trust was designed into the workflow
Human approval checkpoint before execution begins.
Retry loop from validation back to the executor when output quality is not sufficient.
Traceable handoffs between planner, orchestrator, executor, tools, validator, and final response.
Decision boundaries that make it easier to debug why the system took a specific path.
Workflow behavior
How the system moves from input to output
A user task enters the harness as structured workflow state.
The orchestrator routes the task to a planner agent for decomposition.
A human approval checkpoint confirms the plan before execution.
The executor agent uses constrained tool pathways to complete the work.
The validator checks the output and either sends it back for correction or releases the final response.
Tech stack
Technology grouped by responsibility
Orchestration
Agent harness
Control surface
Next improvements
What I would strengthen next
Add a richer evaluation dataset for recurring task categories.
Classify validation failures into clearer categories like tool error, reasoning miss, missing context, or unsafe output.
Add deeper observability around token usage, tool latency, retry frequency, and agent handoff quality.
Adjacent work