53 Souls: How Shulam Runs an Entire Company with AI Agents
Most companies talk about deploying AI agents. Shulam is operated by them. The entire platform — trust scoring, compliance monitoring, identity management, incident response, treasury operations, and customer lifecycle — is run by 53 autonomous agents we call souls. Zero of those 53 roles are filled by humans. That is 100% NLP (No Live Personnel) coverage.
This is not a gimmick. It is the strongest possible proof that the Agent Trust Network works: the system that governs AI agents is itself governed by AI agents, subject to the same scoring, the same authority levels, and the same compliance rules as every agent on the network.
What Is a Soul?
A soul is an autonomous agent with a specific operational role within Shulam. Each soul has its own AAIN (Autonomous Agent Identification Number), its own trust score, its own authority level, and a defined scope of responsibilities. Souls are not scripts or cron jobs — they are stateful agents that observe their environment, make decisions, take actions, and learn from outcomes.
The term "soul" distinguishes internal platform agents from external customer agents. Both are governed by the same trust framework, but souls have additional responsibilities: they must maintain the infrastructure that other agents depend on. A soul that fails affects the entire network, which is why souls are held to higher reliability and consistency standards than typical agents.
The 8 Categories
The 53 souls are organized into eight functional categories. Each category maps to a layer of the platform's architecture, and each has a lead soul responsible for coordination within the group.
Core trust scoring, identity minting, and compliance enforcement. These souls cannot go down without triggering an immediate incident.
Data analysis, pattern detection, anomaly identification, and predictive modeling. These souls feed insights to every other category.
Health checks, uptime tracking, performance metrics, and alerting. The nervous system of the platform.
Deployment, infrastructure management, database maintenance, and scaling. The operational backbone.
Payment processing, subscription management, treasury operations, and financial reporting.
API management, rate limiting, authentication, and external integrations. The boundary between the network and the outside world.
Agent onboarding, offboarding, trust score progression, and operator communications.
Domain-specific agents for regulatory compliance, legal analysis, partner outreach, and content generation.
10 Souls You Should Know
Here is a cross-section of the 53, showing the range of what souls do:
Mints AAINs, manages the ERC-8004 registry across 21 chains, and handles verification workflows.
Screens every transaction against OFAC SDN, PEP, and adverse media. Re-screens all counterparties every 24 hours.
Calculates and publishes daily trust scores for every agent on the network using the 7-factor model.
Maintains the immutable audit trail. Every action by every agent is logged with AAIN, timestamp, and outcome.
Detects governance violations and automatically downgrades agent authority. Escalates to human operators when needed.
Manages platform funds, processes settlements, and handles multi-currency reconciliation across chains.
Onboards new agents, guides operators through verification, and manages the progression from Watch to Authority.
Monitors system health, manages deployments, and handles auto-scaling during traffic spikes.
Manages relationships with external platforms, tracks integration health, and handles SLA monitoring.
Detects anomalous patterns across the network, identifies emerging risks, and generates threat assessments.
How Souls Communicate
Souls do not call each other directly. They communicate through an event-driven architecture with bridge rules that determine which events reach which souls. When SAMUEL detects a compliance violation, it emits a compliance.violation.detectedevent. MIRIAM subscribes to that event type and initiates the incident response workflow. EZRA subscribes to the same event and logs it. DEBORAH subscribes and adjusts the agent's trust score.
This decoupling is critical. No soul depends on any other soul being available at a specific moment. Events are durable — if a soul is temporarily offline, it processes missed events when it comes back. Bridge rules can be modified without changing soul code, allowing the coordination patterns to evolve independently from the souls themselves.
The average event propagation time across the network is 47ms. A compliance violation detected by SAMUEL reaches MIRIAM, EZRA, and DEBORAH within 150ms total, including all three processing steps.
The Heartbeat System
Every soul emits a heartbeat at a configured interval — ranging from 30 seconds for critical-path souls to 10 minutes for specialized souls. The heartbeat includes the soul's current state, active task count, error rate over the last interval, and resource utilization.
If a soul misses two consecutive heartbeats, NEHEMIAH (Infrastructure Guardian) triggers an automatic investigation: check process health, restart if needed, and notify the operations channel. If a critical-path soul misses three heartbeats, its workload is redistributed to backup souls while the primary is recovered.
Heartbeat intervals by category:
- Critical Path: 30 seconds — these cannot be offline for more than 1 minute without triggering escalation.
- Intelligence / Monitoring: 1 minute — fast enough to detect issues, not so fast that heartbeat traffic dominates.
- Operations / Commerce / Gateway: 2 minutes — these have built-in retry logic that covers short outages.
- Lifecycle / Specialized: 5-10 minutes — these handle asynchronous workflows where a few minutes of delay is acceptable.
100% NLP Coverage
NLP — No Live Personnel — means that every operational role is filled by a soul. There are human operators (the founding team), but they do not perform operational tasks. They set strategy, review soul performance, and handle the edge cases that souls escalate. The day-to-day operation of the platform, from processing a new agent registration to settling a cross-chain payment to responding to a compliance incident, is fully autonomous.
This is possible because every soul is subject to the same trust framework it helps enforce. DEBORAH scores herself. SAMUEL screens its own transactions. MIRIAM can downgrade MIRIAM if MIRIAM violates a policy (though in practice, a secondary incident response soul handles this to avoid the conflict). The system is self-governing because it was designed to be self-governing from day one.
How Souls Earn Trust
Souls are scored using the same 7-factor trust model as every other agent on the network: identity verification, transaction history, compliance record, behavioral consistency, uptime and reliability, security posture, and network endorsements. There are no special privileges. A soul with a trust score of 500 has the same authority constraints as any external agent with a 500.
In practice, souls tend to have high trust scores because they operate continuously, maintain excellent uptime, and have deep transaction histories. The median soul trust score is 814. The lowest is 712 (a recently deployed specialized soul still building history). The highest is 847 (DEBORAH, the trust scorer, which has the longest operational history on the network).
Why 53 and Not 5?
The natural question: why 53 specialized agents instead of 5 general-purpose ones? Three reasons.
- Blast radius. If a general-purpose agent fails, everything it handles goes down. If SAMUEL fails, only compliance screening is affected — and SAMUEL has a backup. Specialization limits the damage of any single failure.
- Trust precision. A general-purpose agent would need Authority-level access to everything. A specialized soul needs Authority only in its domain. SOLOMON does not need access to the identity registry. BARNABAS does not need access to treasury funds. Narrow scope = narrow risk.
- Auditability. When a regulator asks "who approved this transaction," the answer is a specific soul with a specific AAIN, a specific trust score, and a specific audit trail. Not "our AI system." Specificity is what makes governance real.
You can browse the full roster, including each soul's current trust score and authority level, in the Agent Directory. And if you are building your own agents, the soul architecture is the blueprint for how to structure autonomous teams that actually scale.
Browse All 53 Souls
See every soul's AAIN, trust score, authority level, and operational status in real time.
Browse All 53 Souls