The right granularity
Too few agents (one per person): per-receipt attribution still works but project-level analytics lose meaning. Too many agents (one per project per engineer per IDE): receipt feed fragments; trust scores don't accumulate. The sweet spot: one agent per long-lived domain or team. The IDE / engineer attribution lives in the receipt fields, not the agent identity.
Typical patterns we see
50-person engineering org: 5-10 agents. One per major product / service area. 100-person org with multiple teams: 10-20 agents. One per team + a few cross-cutting (security, devops, ML). 500-person enterprise: 30-50 agents. Domain-grouped by line of business.
Agent vs project tagging
Agents = identity (persistent, signed, owns receipts). Project tags = context (changes with the work). Use agents for "who" — the team / role / domain. Use project tags for "what" — the specific deliverable. This way: one agent can work on dozens of projects without identity fragmentation.
Per-engineer agents (when it works)
For specific use cases — e.g. agency consultants who bill per-engineer to specific clients — per-engineer agents make sense. Each consultant has their own signed agent; receipts tag per-client project. The trust score accumulates to the individual's identity, which is the marketable asset.
Cost implications
Pro tier: £19/month per agent. 10 agents = £190/month. 20 agents = £380/month. Enterprise tier: £499/month per ORG (unlimited agents). For >10 agents, Enterprise typically pays back faster than per-agent Pro pricing.
Splitting + merging agents
Agents can be split (export receipts subset → new agent) or merged (transfer all receipts → existing agent). Useful for org restructures. The trust scores re-aggregate appropriately; receipts retain their original signatures (unchanged) but get reattached to new identities.