Code-aware crews: entity-level task partitioning and verification for coding agents

[rs545837]

Crews of coding agents hit three problems single agents don't: every agent re-reads the same code to build the same mental model, the manager splits work blindly so agents edit code that depends on each other, and reviewing per-agent changes means reading raw diffs.

These are all graph problems. sem builds a deterministic cross-file entity graph (functions, classes, methods) over any git repo and ships as an MCP server, so it works with MCPServerAdapter today:

from crewai_tools import MCPServerAdapter

sem_tools = MCPServerAdapter(
    server_params={"command": "sem", "args": ["mcp"]}
)

Per role:

• Manager: sem_impact gives blast radius, so tasks can be partitioned into non-overlapping subgraphs before delegation.
• Workers: sem_context returns a function plus its callers and callees in one call, 50-65% faster than grep-and-read loops for structural questions in our benchmarks.
• Reviewers: sem_diff reports each agent's changes as modified entities, not raw diffs.

To be upfront: for a single agent on an ordinary fix, sem is roughly at parity with grep. The win is specifically multi-agent, where one shared graph replaces N private explorations.

Happy to contribute a cookbook example or docs page if there's interest.

[yashwant1810]

Hey @rs545837 - good idea, the framing around graph-based partitioning for multi-agent crews helps address some of the issues i've noticed personally, mainly along blind delegation & redundant exploration.

I've started to dig around on this more, & started with a initial implementation for this.

Few questions as we more deeper :

1. Partition granularity: You mention non-overlapping subgraphs, does sem_impact already handle the case where two entities share a file? i.e., does it give enough info to enforce "all entities in the same file go to the same partition" without extra logic on our side?

2. As for Context budget: For sem_context, is there a built-in way to limit how deep the caller/callee graph goes, or would we need to implement truncation on the crewAI side to prevent context window blowout on highly-connected entities?

3. Finally as for diff baseline wrt sem_diff, what do we compare? the last git commmit, a snapshot taken before the worker starts or some other ideas.

Happy to collaborate on this. Will share my work on this soon!!

[shaozhengkun123]

I would make the integration contract explicit rather than let each crew infer these three choices differently:

1. Partition ownership: start with one writer per file. If two entities in the same file land in different subgraphs, either assign the whole file to one worker or make the other workers read-only and merge through a single owner. A simple acceptance condition is: no two concurrent workers receive write scope to the same path.

2. Context budget: cap by a token budget, not only graph depth. Traverse outward by distance and edge importance, stop before the fixed budget, and return the omitted frontier as metadata. Test this on high-degree hubs and report p95 context size plus whether required dependencies were omitted.

3. Diff baseline: capture an immutable tree/commit SHA when the worker claims the task. Compare the worker result to that baseline, then separately detect drift against current HEAD at review time. Using only “last commit” becomes ambiguous once workers commit concurrently.

That gives a small acceptance matrix: no overlapping write paths, bounded p95 context, and a diff tied to an immutable task-start baseline. It should be testable before deciding whether sem itself or the CrewAI adapter owns each policy.

[IgorGanapolsky]

Reliability note

Production automation failures usually reduce to a contract issue before a model/prompt issue:

1. Success criteria — durable artifact id (message/booking/row), not only node green
2. Side-effect before complete — never blind-retry without an idempotency key on the business object
3. Tool vs path split — external action can succeed while the node/agent path still errors (silent-green / false-red)

If you have one failing execution + expected vs actual, reply with stack/version and I will send a free root-cause checklist.