Generic Entity Scoring Engine, Native to the CRM
“The hard problem is not adding an agent. It is deciding which agent - and whether any agent - should act.”
An independent agent-orchestration study: one deterministic scoring algorithm applied unchanged to any entity, routing to narrow specialists, with every mutation gated behind schemas.
ORCHESTRATORENTITY SCORINGTOOL CALLINGMULTI-AGENT
Unready fixtures stop before any model call, with a machine-readable reason
What Made the Problem Difficult
Independent prototype, synthetic data. I built this because single-agent demos kept failing the same way in my experiments: one bloated prompt, thirty tools, and no notion of whether the record was even ready. The engine is deliberately generic - the same scoring algorithm runs unchanged across different fixture entities, so readiness means the same thing everywhere instead of being redefined per object. I wanted that boring machinery - scoring, routing, gating - treated as first-class architecture instead of prompt tricks.
Core Platform Constraint
Systemic FrictionWhat goes wrong without it: models get invoked on incomplete records, contexts bloat across domains, tools fire with unvalidated arguments, and nobody can reconstruct why an action happened. In record-centric work that is unacceptable.
- !No model call on unready records - deterministic triage first
- !Every mutation behind schema validation and permission checks
- !One specialist per task with an isolated context window
- !Full reconstruction: scores, routes, and tool I/O all auditable
What System Was Designed
Three stages, deliberately unglamorous: 1) Score - completeness, urgency, and risk computed deterministically over the fixture record. Below threshold, the orchestrator stops and says why. 2) Route - an intent classifier picks exactly one specialist and hands it a fresh, narrow context. 3) Act - the specialist may only call registered tools whose arguments validate against strict schemas; every call and result lands in an audit envelope.
Pivotal Architectural Choices
Key Architectural Decisions
Score-first triage vs. immediate generation
Calling a model on a half-formed record wastes tokens and invites confident nonsense.
- Prompt directly on the raw record
- Hardcoded triggers with no model at all
Cheap arithmetic filters most cases; expensive inference runs only where it can help. My logs showed fewer wasted calls and clearer refusals.
Narrow specialists vs. one mega-prompt
One agent holding quoting, SLA, and billing logic degrades at all three.
- Single prompt with 30+ tools
- Uncoordinated agent swarm
Small contexts stay sharp. Routing decisions stay visible. Debugging stops being archaeology.
What Was Actually Built
Built the scorer as pure functions over fixture records - no model involved, fully unit-testable thresholds.
Implemented the router as intent classification plus capability matching, with explicit abstention when nothing qualifies.
Registered every tool with a strict JSON schema; validation failures return structured errors, never partial writes.
Wrapped each run in an audit envelope: input hash, scores, route taken, tool calls, outputs, timestamps.
Gave each specialist a fresh context assembled from the envelope - never the full conversation history.
Deliberate Architectural Compromises
Trade-offs & Mitigations
⚖Routing hops vs. single-shot latency
Guardrails, visibility, and far fewer runaway actions.
Extra milliseconds per run for scoring and routing.
Precomputed score vectors and parallel skill-eligibility checks keep the overhead small.
⚖Schema gates vs. freeform tools
Invalid mutations die at the boundary with a reason attached.
Each capability needs a written schema and mapping.
A small tool template keeps new capabilities to one file each.
Verified Outcomes
Unready fixtures stop before any model call, with a machine-readable reason
Specialist contexts stay small and task-shaped across multi-step fixture runs
Schema gates catch malformed tool arguments before any state change
Every run reconstructs end to end from its audit envelope
System Schematic & Data Flow
Triage before tokens: score, route to one specialist, and gate every tool call behind schemas.
Text alternative for screen readers: Architecture flow: Record Ingress (synthetic) to Orchestrator via State & Intent Intake; Orchestrator to Scoring & Routing via Readiness Triage; Scoring & Routing to Specialist (A/B/C) via Isolated Delegation; Specialist to Tool Registry via Schema-Gated Execution
Architectural Conclusion
“Agents become trustworthy when the unglamorous parts - scoring, routing, gating - are engineered instead of prompted.”
- •Score before you generate; most enterprise records are not ready on arrival.
- •Small routed contexts outperform large shared ones in every run I measured.