Kyc aml · Production

Building AI Agents in Production: Parcha's Lessons on Async Architecture, Multi-Agent Coordination, and Error Recovery

The problem

Parcha's initial naive approach to building AI agents for compliance and KYB workflows suffered from WebSocket reliability issues, context window overload from single-agent SOPs, no error recovery mechanisms, LLM hallucinations causing tool failures, and tightly coupled agent implementations that could not be reused.

First attempt

Parcha's initial build used WebSocket connections for bi-directional communication, a single agent with the full SOP embedded in its scratchpad, the scratchpad alone for memory, and no failover or exception handling, causing the agent to fail unrecoverably on any step error.

Workflow diagram · grounded in source
1
Agent triggered via API or Slack
trigger
“agents can be triggered through an API, followed through a Slack channel (they start threads and provide updates as replies until completion), and evaluated at scale as headless processes”
2
Coordinator plans from master SOP
ai_action
“The coordinator develops an initial plan using the master SOP and delegates subsets of the SOP to "worker" agents that gather evidence, make conclusions on a local set of tasks, and report back to the coordinator”
3
Worker agents gather evidence
ai_action
“a coordinator triggers a worker agent to perform each and report back. The coordinator would decide if - per the SOP - the customer should be approved or not”
4
Document extraction step
ai_action
“We now ask the LLM to extract the relevant information from the document (e.g., is it valid? What's the company being mentioned, and which state/country is it incorporated in?)”
5
Separate judgment step
validation
“Then in a second trip to the LLM, we ask it to compare the information (removing the unnecessary elements from the document) from the self-attested information”
6
Agent self-correction on error
feedback_loop
“we are now leveraging well-typed exceptions in our tools to feed them back to the agent. If a tool fails, we send the exception name and message to the agent, allowing it to recover independently”
7
Human escalation when needed
human_review
“an assessment of approving/denying/escalating to humans an application”
8
Final recommendation output
output
“the coordinator uses all the evidence workers gather to develop a final recommendation”
Reported outcome

Parcha rebuilt their agent architecture with async long-running tasks via pub/sub, a coordinator/worker multi-agent model to contain context windows, Redis-based shared memory, well-typed exception handling for agent self-correction, and reusable composable tool building blocks, significantly reducing catastrophic failures.

Reported metrics
Catastrophic agent failuresreduce the number of catastrophic failures significantly
Reported stack
Langchain AgentsRedisRQOCRSlack
Source
https://resources.parcha.com/building-ai-agents-in-production/
Read source ↗

Frequently asked questions

What did this team achieve with this AI workflow?

Parcha rebuilt their agent architecture with async long-running tasks via pub/sub, a coordinator/worker multi-agent model to contain context windows, Redis-based shared memory, well-typed exception handling for agent…

What tools did this team use?

Langchain Agents, Redis, RQ, OCR, Slack.

What results were reported?

Catastrophic agent failures: reduce the number of catastrophic failures significantly (source-reported, not independently verified).

What failed first in this deployment?

Parcha's initial build used WebSocket connections for bi-directional communication, a single agent with the full SOP embedded in its scratchpad, the scratchpad alone for memory, and no failover or exception handling,…

How is this kyc aml AI workflow structured?

Agent triggered via API or Slack → Coordinator plans from master SOP → Worker agents gather evidence → Document extraction step → Separate judgment step → Agent self-correction on error → Human escalation when needed → Final recommendation output.

Related kyc aml cases