An exploration of LangChain and LangGraph

A Config-Driven Agent Network

By John Fisher. A working prototype, with the orchestration live and the agent data mocked.

A network of specialist AI agents, coordinated by a broker, with a human approval gate on anything consequential. The point of the project is that the network is data, not code: the agent roster, the routing prompts, the demo scenarios and the definition of what counts as risky all live in an XML file. Point the loader at a different file and the same graph becomes a different business.

2agent networks defined
10agents across both
10demo scenarios
0code changes to swap domain

What is real, and what is not. The orchestration runs: the LangGraph state machine, the routing, the synthesis and the human gate all execute against gpt-4o. Every agent's answer is written into the config file in advance, in its <mock_data> block. Nothing is fetched: no vendor API is called, and no MCP server exists. The design notes name candidate integrations, rate-shopping feeds, property management systems, flight capacity data; none of them are built.

That is a data-protection decision before it is a convenience one. Wired to live systems, a network like this would read real rates, booking records and guest reviews, and forward whatever it found to a language model. With every answer written in advance, the only things that leave your machine are the question you type and text you can read in this repository. It also makes a run repeatable, which is what lets the test suite exercise the real graph with no key, no network and nothing spent.

This is a study of a pattern, not a product, and nothing here evidences a business outcome.

How a question moves

A partner states a problem in their own words. They do not choose an agent, and they do not need to know the roster exists. The broker reads the intent, decides which specialists are relevant, and delegates. The specialists run in parallel and report back. The broker then does the part that makes the network worth having: it combines findings that no single agent could have reached alone, and it scores the risk of its own recommendation.

One question through the networkThe broker decides who to consult, waits, synthesises, and scores the risk of its own recommendation.a questionBROKERdecides who to consultMarket Scoutevents, weatherRevenuepricing, ratesContentlisting qualityGuest Exp.reviewsFacilitiesmaintenancethe specialists run in parallel, each returning its canned replyBROKERsynthesises, scores riskrisk rule fires?noyesHUMAN APPROVALthe approved text is returned verbatimthe answer
Figure 1. The broker fans out to the specialists it selected, fans back in, and routes to a human only when its own risk rule fires. Two calls to the model per question, one to route and one to synthesise; the specialists cost nothing, because their answers were written in advance.

The specialists

Each agent advertises what it is good at. That description is the only thing the broker sees when it decides who to consult, which means adding an agent is a matter of describing it well, not of editing a router.

Market Scout

Watches events, weather and travel demand, so a booking dip can be traced to a cause outside the property.

Revenue Strategist

Compares your rates against the competitive set and recommends a move, with the reasoning attached.

Content Specialist

Audits the listing: photographs, description, amenity tags, and whether it will surface in the right filters.

Guest Experience

Reads reviews for sentiment and recurring operational complaints.

Facilities Manager

Knows the physical state of the property: housekeeping, maintenance, what is in the store cupboard.

The same code, a different business

The travel network is one configuration. Here is a second: a management consulting firm, with five different specialists, a different router prompt, and a different definition of risk. It runs on the same graph, loaded the same way, with nothing swapped but a path.

Two businesses, one graphNothing below the configs changes. No node, no edge, no line of Python.config_travel.xmlMarket Scout, Revenue Strategist,Content Specialist, Guest Experience,Facilities ManagerRisk rule: changing prices orpublishing content needs a human.config_agency.xmlMarket Analyst, Financial Modeler,Organizational Strategist,Operations Specialist, Risk & ComplianceRisk rule: layoffs, restructuring orbudget moves over $1M need a human.the same graphagentic_network/graph.py, unchanged
Figure 2. Two configurations, one graph. The specialists, the prompts, the scenarios and the risk rule are all data.

This is the part worth taking away. In most agent frameworks the roster is expressed in code: a class per agent, a router with a branch per destination, edges wired by hand. That works until the roster changes. Here, the graph is constructed at load time from whatever the config declares, so a new agent is a new XML block and a new domain is a new file.

The human gate

Some recommendations are cheap to be wrong about. Reporting that guest sentiment is neutral costs nothing if it is mistaken. Dropping your room rate by $50 is different, and so is a recommendation to reduce headcount by ten percent. The synthesis step scores each answer against a rule from the config, and anything above the line stops for a person.

Approval must return the approved text. It is tempting to route an approval back through the synthesis step, and that quietly defeats the gate: what the user receives is then a second generation, which can differ from what they authorised. Here the gate is terminal and hands back the proposal verbatim, with a test asserting that it appears unchanged in the final answer.

Nothing about a regenerated answer looks wrong from outside: the system stops, a person approves, and a plausible answer appears. The architecture page has the detail.