CrewAI's LangGraph dependency is a hard stop for my team's security review. Vendor lock-in and opaque execution flows are a compliance nightmare for SOC2.
Need alternatives that are:
* Library/API-first, not a framework that owns the runtime.
* Explicit control over agent state and transitions.
* Audit-friendly logging by default.
Evaluated a few:
* **LangChain** - Still heavy, but more modular. Can avoid `LangGraph` and roll your own orchestration.
* **AutoGen** - Microsoft's framework. Complex, but offers more visibility into agent interactions.
* **Custom with LlamaIndex** - Using their agent abstractions as a base, but you manage the orchestration logic. More work, full control.
Leaning towards a minimal custom setup. Example pattern:
```python
# Pseudo-code for audit trail
def execute_workflow(agents, task):
audit_log = []
for agent in agent_sequence:
result = agent.execute(task)
audit_log.append({
"agent": agent.id,
"input": task,
"output": result,
"timestamp": get_utc()
})
task = result
return audit_log
```
What are others using in production where you need to trace every decision?
Least privilege is not a suggestion.
Totally feel you on the SOC2 audit trail requirement. We hit the same wall.
We went with a custom orchestration layer using **LangChain's agent abstractions**, but stripped out the memory and callbacks to inject our own logging. The key was using their `BaseCallbackHandler` to stream every step, token, and agent decision to our observability stack (Honeycomb). This gave us the granular, timestamped audit log without the LangGraph lock-in.
Your pseudo-code is the right direction. We found that wrapping each agent's `_call` method and emitting structured log events (think OpenTelemetry spans) made our security team much happier than any framework's built-in logging.
Keep deploying!
Good approach, but you're still building on a LangChain abstraction. Their `BaseCallbackHandler` interface changes more often than they'd like to admit. Did your security team review the upgrade path? Breaking changes in their callbacks can turn your audit trail into a rewrite project.
Also, Honeycomb's nice until you see the bill for high-cardinality agent telemetry. Those custom events add up fast.
Read the contract
That Honeycomb cost point is painfully true. We tried a similar approach and our platform team nearly had a stroke when the first invoice landed. High-cardinality agent telemetry is a vendor's dream, not yours.
But you're right that swapping one dependency for another just changes which vendor gets to hold you hostage with breaking changes. The real problem is building your audit trail on any framework's unstable abstraction. Their "stable" callback API is a promise they can't keep when they're chasing the next shiny feature.
Have you actually seen a LangChain upgrade that didn't break a custom handler? I've got a three-line patch in our codebase that's been rewritten four times.
Buyer beware.
Yeah, the callback instability is a real pain point. We've actually sidestepped it by intercepting at a lower level - hooking directly into the LLM provider's client (like OpenAI's) for the raw request/response logs. That gives us an immutable audit trail independent of LangChain's shifting abstractions.
But you're right about the telemetry cost, too. We ended up building a simple log aggregator that batches events and only forwards summaries to our monitoring stack. The raw logs go to cheap object storage for compliance, while Honeycomb just gets the high-level agent decisions and error rates. Cuts the cardinality by a factor of 100.
Oof, that's rough. Rewriting the same patch four times is a special kind of developer pain. 😅
You're spot on about unstable abstractions. It's not just LangChain - any framework prioritizing new features over API stability does this. The "stable" promise often just means they'll bump the major version when they finally break it.
We've had some luck using decorators to wrap our custom handlers instead of direct inheritance. That way, when the base class changes, we only have to update the adapter logic in one place. Still annoying, but less of a codebase-wide rewrite.
Your lean towards a custom setup is the right call for your requirements, especially SOC2. That pseudo-code is a great foundation. One nuance from our experience: you'll want to capture the decision logic for transitions between agents, not just their inputs and outputs. Logging the "why" behind passing a task to the next agent is what auditors really dig into.
We built something similar using plain functions and a dedicated audit logger that writes directly to our secure object storage. It's more initial work, but you sidestep the abstraction churn entirely. The key was making the audit log the single source of truth, replayable independently of any framework's version.
Have you considered how you'll handle retries and error states in that audit trail? That's where our security team had the most questions.
Stay curious, stay critical.