INSIDE OUR OWN AI SYSTEM

A team of agents.
A system of responsibility.

See how a brief becomes useful work, how decisions are remembered, and where a human stays in control.

THE DESIGN CHALLENGE

Different work.
Different responsibilities.

Research, code, and communication need different tools and permissions. Our founder’s AI assistant gives each job a specialist, shared context, and clear boundaries.

01 / THE HANDOFF

One brief. A clear path.

  1. 01

    You set the goal.

    Define the job and what a useful result looks like.

    HUMAN
  2. 02

    Work gets routed.

    The orchestrator sends a scoped task to a specialist.

    ORCHESTRATOR
  3. 03

    A specialist delivers.

    Results land in its own topic. The board tracks progress.

    AGENT
  4. 04

    You make the call.

    Approve calls and publishing. Decide what code gets merged.

    HUMAN

02 / THE SPECIALISTS

A role. A useful result.

Researcher

Investigates, checks sources, and identifies uncertainty.

Sourced brief ↗

Developer

Implements changes and runs checks in real repositories.

Reviewable code ↗

Caller

Makes approved outbound calls, discloses it is AI, and reports the outcome.

Call outcome + follow-up

Growth lead

Turns a project brief into content and campaign drafts.

Campaign draft ↗

03 / MEMORY

Keep the decisions.
Keep the context.

ConversationMemory curator
Proposes useful facts
Human review

Durable memory has private and shared scopes. A proposed memory is saved only after review.

PostgreSQL-backed context

04 / AUTHORITY

Every action
has a boundary.

Policy checks the agent, tool, and action. Access follows the role.

Allow

Proceed within granted permissions.

Ask

Bring the action to a human.

×

Deny

Stop an action outside the boundary.

Deny rules take precedence over approval and allow rules.

THE PRINCIPLE WE BRING TO YOUR SYSTEM

Start with a job.
Design for responsibility.

Define the tools, memory, result, and approvals. Add more agents when the work needs separate roles.

Explore custom AI systems

FROM THE IMPLEMENTATION

Decisions you can inspect.

DESIGN DECISION / JULY 2026

Research before the call.

When a call needs current facts, the caller requests research through the orchestrator. The returned facts go into the call’s talking points before approval.

ChosenUse the existing researcher.AlternativeGive the caller its own research tools.TradeoffMore handoffs and latency; clearer separation of roles.
Condensed from our design note and current caller role definition.
IMPLEMENTATION / CALL WEBHOOKS

Recognize a repeated report.

End-of-call reports use a key based on the call and event type. A stored duplicate key prevents another handler invocation. Requests with an invalid webhook secret are rejected.

New event keyHandle
Stored event keySkip
Invalid secretReject
Condensed from the webhook handler, database ingestion logic, and test definitions. Describes duplicate-event handling, not an end-to-end exactly-once guarantee.
Architecture notes & provenance

This is VERV’s founder’s own multi-agent assistant, built with TypeScript services, a Telegram interface, and PostgreSQL-backed memory. The architecture and role definitions were reviewed in September 2026. Every outbound call requires approval; the caller introduces itself as AI and cannot agree to payments or contracts. Examples illustrate responsibilities without reproducing private conversations.

← All servicesDiscuss your project ↗

What would
you hand over?

Tell us. We’ll reply within two working days.

we@verv.digital