Two real layers, not brand personas
REVsign OS has two layers of agent architecture. They aren’t an aspirational diagram, they’re the canonical naming over symbols that already run in production. Layer 1 is what the client buys and sees: three functional engines. Layer 2 is what holds that layer up from underneath: seven atomic sub-agents, each with constraints fixed in code, not in a written instruction a model could misread.
Layer 1, the three functional engines
| Engine | What it does | Real symbols |
|---|---|---|
| Discovery and Signals | Discovers intent signals for campaigns | Market radar, listening processes (software in use, intent signals, weekly scan) and scoring by fixed rules by stack-category delta |
| Outreach and Second Brain | Processes priority accounts with the account’s institutional memory | Prospecting flow, campaign drafting and account-context injection (institutional memory block) and two-step lookup by real function |
| Expansion and Customer Telemetry | Active accounts: prevents early churn and detects cross-selling | Account-expansion flow, “white space” tool, and snapshots of the software in use |
Honest precision about the mapping
There are two real work flows in the code, not three. The Discovery and Signals engine is not a work flow: it is the radar and ingestion layer, the central router plus the cron-driven listening functions, that feeds the other two engines. Documenting a three-flow symmetry the code does not have would repeat the same mistake that already got an earlier layer of brand names on these agents discarded: promising a shape the real system doesn’t have.
Layer 2, atomic sub-agents: the digital straitjacket
The seven sub-agents run under code-enforced constraints: model, per-call writing cap, iteration cap, and an explicit list of allowed tools. That list isn’t a suggestion a model could ignore under pressure, it’s a filter over the tool descriptors themselves: an agent never even sees a tool that is not on its list.
| Agent | Task | Model | Tope de escritura | Iterations | Tools |
|---|---|---|---|---|---|
| Diagnóstico de cuenta | Analysis of the infrastructure and the software in use | Sonnet | 4096 | 3 | 2 lookups + signal insert |
| Búsqueda de contactos | Contact lookup by real function | Sonnet | 4096 | 4 | 2 |
| Radar de mercado | Market radar and empirical environment validation | Sonnet | 4096 | 3 | 1 lookup + signal insert |
| Redacción de borradores | Multichannel asset drafting with the output shape fixed in advance | Sonnet | 8192 | 2 | none |
| Cálculo de impacto | Quick impact calculation | Haiku | 2048 | 1 | none |
| Clasificación de perfil | Evaluates a contact’s real function | Haiku | 1024 | 1 | none |
| Lectura rápida de una señal | Handles a queue of fast alerts | Haiku | 1024 | 1 | none |
Why the persona classifier runs on the smallest model
It isn’t a quality shortcut, it’s the economic control for late reveal. The persona classifier evaluates a contact’s functional fit before any billed enrichment call, email or phone, ever fires. Running it on the fastest, cheapest model in the family, with a single iteration and no tools, keeps that upstream filter close to free. Real spend only fires after this agent has already approved the fit. The full late-reveal protocol is covered in FAQ. The role-based read on it (what it proves for a CFO, what it automates for RevOps) is in Role-Based Use Cases.
The constraint is shown, not promised
That a client can see the exact writing cap and tool list for every agent is, itself, the argument: the discipline isn’t an internal policy stated in a sales document, it’s a verifiable property of the system as it actually runs.
Frequently asked questions
Is “functional engines” just another name for named brand personas?
No, it’s the opposite. It’s the naming that replaced an earlier brand-persona proposal over these same agents, discarded specifically for introducing a naming layer that existed neither in the code nor in the client console. The three functional engines are a canonical label over real pieces, not characters.
Why does the persona classifier run on the smallest model in the family?
It isn’t a quality shortcut, it’s the economic control for late reveal. It evaluates a contact’s functional fit before any billed enrichment call ever fires. Running it on the fastest, cheapest model, with a single iteration and no tools, keeps that upstream filter close to free. Real spend only fires after this agent has already approved the fit.
$ curl revsign.os/docs/agent-architecture
→ {
title: "Agent Architecture: The Three Functional Engines and the Digital Straitjacket",
answers: "What AI agents does REVsign use, and what stops them from acting outside their function?",
schema: [TechArticle, FAQPage]
}