Success IT · Officers' briefingTechnical architecture + live demonstration
27 August 2026

How our AI
agents work.

People remain accountable. Agents extend what they can do.

Jensen Loke · CEO, Success IT01 / 10
AI journeyOperational pressure → repeatable capability
Why we built it

Each agent began with a recurring piece of work.

01 · HUMAN WORK

Customer conversations

Issues arrive in natural, incomplete language.

02 · ZACH

Structured support

Customer context, tickets and tracked handoffs.

03 · INSA

Technical reach

Product routing, investigation and proposed changes.

04 · LAYLAH / PEGGI

Operational workflows

PA, communication and finance-specific processes.

05 · MANAGEMENT

Improve the system

Fix the reusable workflow when an agent cannot help.

Our unit of design is the workflow—not the chatbot.02 / 10
System architectureSeparate workspaces · tools · routes · permissions
The whole operating system

Four agents. Four bounded responsibilities.

Humans
IrisCustomer meaning and ticket review
JianzhiProduct scope and business verification
Jensen / teamApproval, release and escalation
Agents
Zach · Support operationsEmail/Discord → context → ticket → engineering handoff
Insa · Product engineeringProduct lane → impact check → investigation → PR package
Laylah · Business operationsPrivacy-aware routing → PA tools or restricted support intake
Peggi · Finance in CodexFinance skill → duplicate check → draft → approval → record
Systems
SuccessCatalyst + SuccessGraph
CodeGraph + product software + databases
Email + calendar + WhatsApp + Obsidian
SuccessBooks + finance knowledge store
HumanAgentSystem / dataApproval
Source: live OpenClaw configuration and Codex finance workflow audited 26 Aug 2026.03 / 10
Top-down architectureInterface → routing → graph → CLI → systems → supervision
The technical stack at one glance

System access is routed through tools, graphs and CLIs.

People + channels
Iris · Jianzhi · JensenDiscordEmailWhatsAppTelegram
OpenClaw gateway
Account bindingChannel / peer routerSession isolationModel runtime
Agent workspaces
ZachInsaLaylahPeggi / CodexSeparate memory + tool allowlists
Workflow graphs
zach-workflowsinsa-workflowsZach↔Insa handoff graphapproval checkpoints
Deterministic tools
SuccessCatalyst CLISuccessGraph clientCodeGraph CLIinspectdb-clisafe SQL / Git / email scripts
Business systems
Tickets + customersProduct repositoriesTenant databasesGitHub PRsEmail + Discord evidence
Control plane
cron schedulesSQLite checkpointsJSONL audit logswatchdogs + EOD reconciliationhuman approval
Source: live gateway bindings, workflow-plugin contracts and operational state.04 / 17
Agent 01 · ZachNatural conversation → structured support work
Demo owner · Iris

Zach is the support operations layer.

SuccessGraph is the customer map: it links companies, products, subscriptions and the correct support route.

Configured tool familiesreademail · createticket · readticket · updateticket · zach_group_permissions · zach_github_issue_flow · zach_engineering_delegate
Public-safe SuccessGraph customer map
1
Iris describes the issue naturallyCustomer symptom, urgency and available evidence
→
2
Zach resolves customer and product contextGroup permissions + SuccessGraph + product map
→
3
Ticket tools create or update the recordSuccessCatalyst becomes the durable source of truth
→
4
Iris checks meaning and completenessMissing evidence returns to the human
→
5
Qualifying technical work is handed to InsaTracked owner, evidence packet, deadline and escalation
✓
Client interaction remains human; Zach structures and routes the backstage work.04 / 10
Zach · execution architectureRegistered tool → graph operation → CLI → checkpoint
Deterministic below the conversation

Zach's tools are graph-backed commands.

The agent chooses a registered tool. The workflow graph controls what executable path can run and what evidence must be stored.

zach-workflows.sqlite
zach-workflow-runs.jsonl
state.sqlite + approval queue
Natural requestIris, support email or Discord command
↓
OpenClaw tool contractticket create/update · email send · permissions · GitHub issue · engineering delegate
↓
Zach task-chain graphdraft / plan / approval / execute operation with a thread ID
↓
CLI and script layerSuccessCatalyst CLI · SuccessGraph client · MGC email · inspectdb-cli · state_db.py · GitHub helpers
↓
Business resultticket, comment, status, customer context, email, issue or tracked Insa packet
↓
Checkpoint + auditstatus, redacted command, approval state, timestamp and durable next action
Source: zach-workflows plugin contract and zach_task_chains/task_chain_graph.py.06 / 17
Zach · cron control planeIntake · monitoring · reporting · reconciliation
Automation that keeps the workflow moving

Zach is supervised continuously—not only when someone messages him.

Every 10–15 min
Support inbox runner15 min weekdays · 30 min weekendsAgent task watchdog10 minZach→Insa investigation watchdog15 min
Every 2 hours
Workflow visibility report:10 · 08:00–22:00Cron + health audit07:00–23:00
Daily
Morning workload report08:00 weekdaysSupport digest18:00 weekdaysEnd-of-day journal23:00
Weekly
Ticket index syncMonday 07:00Meeting prepWednesday 09:00Ticket review + knowledge patternsFriday 17:00 / 18:00State cleanupSunday 23:45

Fast loops move work. Slow loops detect drift, improve knowledge and keep state bounded.

Source: enabled live OpenClaw cron registry audited 26 Aug 2026.07 / 17
Cross-agent workflowZach↔Insa handoff graph
Ownership survives the chat session

A separate graph decides who owns the next action.

Inputs
Support ingressEmail cron, Discord trigger or scan
Evidence packetTicket, product, symptom, screen and impact
Operational signalsWorkflow report, investigations, heartbeats and watchdogs
→
Graph
Validate evidenceMissing facts block or return to Zach
Reconcile stateZach ledger + Insa investigation + timers
Resolve owner and statusdeterministic decision + durable run ledger
→
Outputs
Zach handlesSupport record or missing evidence
Delegate / wait for InsaTracked investigation with deadline
Human approval / escalationStale, risky or unhealthy workflow
Minimum handoff packet: ticket · product · tenant/customer · exact screen path · sample record · screenshot/error · expected vs actual behaviour · user impact · attempted steps
Source: scripts/ops/zach-insa-handoff-graph.ts and tracked investigation ledgers.08 / 17
Insa · Discord architectureChannel identity becomes product scope
Discord is the front door and the first boundary

The channel selects the product workroom before investigation begins.

Discord channel

Who and where?

  • #insurance-jianzhi
  • #workshop-jianzhi
  • #expat-dev…dev7
  • General, support or domain intake
→
Channel registry + lane resolver

Which product boundary?

  • Product code and specialist mode
  • Intended user and DB approver
  • Repository and workspace
  • Branch base and PR target
  • Environment and endpoint
→
Loaded product context

How should Insa work?

  • Product runbook
  • Workflow-quality playbook
  • Query patterns and schema cache
  • Active investigations
  • Product-specific safety gates
39 configured Discord channels10 product profilesSeparate lanes for Iris, Jianzhi and other staffChannel scope does not grant production-write authority
Source: Insa channel-registry.json v2 and resolve-work-lane.mjs.09 / 17
Agent 02 · InsaProduct-scoped investigation and proposed change
Demo owner · Jianzhi

Insa works inside a configured product lane.

CodeGraph maps software dependencies. A DB is the product database. A PR is a proposed code change awaiting human review.

Configured workflow toolsinsa_product_lane · insa_codegraph · insa_db_diagnostic · insa_investigation_flow · insa_readiness_gate · insa_pr_package · insa_coding_delegate
Public-safe CodeGraph software impact map
1
Jianzhi asks inside a product Discord channelBusiness behaviour, exact scope and evidence
→
2
The channel router selects one product laneRepository · database · branch · endpoint · permissions
→
3
CodeGraph checks likely impact firstThen read-only DB diagnostics, code tracing and reproduction
→
4
Insa prepares a diagnosis or proposed changeReadiness gates, build/test evidence and PR package
→
5
Humans review, release and verifyJianzhi verifies behaviour; Jensen or an engineer controls release
✓
Source: current Insa channel registry, tool allowlist and engineering runbooks.05 / 10
Insa · technical toolchainImpact · data · workflow quality · delivery
The graph selects narrow CLI operations

Each tool answers a different technical question.

CodeGraph CLI

What could this change affect?

Maps components, services, APIs, procedures, tables and reports across products.

find · search · context
flow · table · blast
upstream · downstream
diff · clusters
inspectdb-cli

What is happening in this tenant?

Resolves the database from a company code and records the business reason.

tenants · tenant-info
schema · diagnose
query (read-only)
user lookup / unlock-plan
Runbooks + gates

What evidence is required?

Product playbooks constrain investigation order, SQL safety, UI tracing and release readiness.

investigate-start
workflow-readiness
quality-gate
fix-ready
record-build-artifact
Git + coding delivery

How does a proposal become reviewable?

Clean worktree, safe GitHub commands, verified PR evidence and optional ACP coding delegation.

ensure-clean-worktree
safe-gh pr create
done-ready
Codex / Claude ACP
Discord artifact delivery
Source: Insa graph operations, CLI help and product engineering runbooks.11 / 17
Insa · automation control planeEvent-driven work · scheduled supervision
Discord starts the work; cron checks that it survives

Insa's scheduled jobs monitor ownership, progress and evidence.

On message
Discord product lanechannel → context → investigationWorkflow-graph checkpointthread ID + operation + status
Every 10 min
Insa coding monitorinsa-heartbeat.mjs --check-onlyShared agent task watchdoglong-running task progress
Every 15 min
Zach→Insa investigation watchdogquiet or overdue ownership
Every 2 hours
Cross-agent workflow reportpending · processed · closed · approval stateGateway / bot health reportingshared runtime visibility
23:20 daily
Insa EOD journalreconcile investigation and action ledgers
active-investigations.jsonagent-actions.jsonzach-followup-queue.jsoninsa-workflows.sqliteinsa-workflow-runs.jsonl
Source: enabled cron registry and Insa durable-state protocol.12 / 17
Agent 03 · LaylahPrivacy-aware routing + least-privilege tools
One identity · different permission envelopes

The route decides what Laylah is allowed to do.

Main PA profile

Personal and business coordination

  • Email drafting and sorting
  • Calendar preparation and approved changes
  • Meeting prep, follow-up review and work capture
  • Obsidian search/read/write and PA memory
  • Can consult Zach or Insa as sibling agents
Preview → Jensen approval → external write
Restricted support profile

Customer WhatsApp support intake

  • Activated only in explicitly mapped groups
  • Uses the mapped customer as source of truth
  • Can call only one unified intake workflow
  • Cannot read ticket status, browse, run shell or use general messaging
  • Sensitive requests escalate privately to Jensen
only: successit_support_intake
Source: live bindings, Laylah tool boundary and Success IT support runbook.06 / 10
Agent 04 · PeggiFinance workflow transitioning to Codex
A different runtime · the same principle

Peggi is becoming a finance capability inside Codex.

Earlier / still configured

OpenClaw Peggi

Discord-routed finance agent with SuccessBooks workflow tools, local state and accounting controls.

Workflow examplesexpense entry · duplicate gate · invoice flow · month-end review · billing tracker
→
Current working direction

Codex + Peggi finance skill

Finance requests are classified, sourced and stored in the SICS Accounting knowledge structure; operational tooling remains available for controlled finance work.

Guarded pathsource → classify → duplicate check → dry run → preview → Jensen approval → record
No final accounting, tax, payroll, banking or compliance decision is made without Jensen's confirmation.
Source: current OpenClaw Peggi configuration and Codex Peggi Finance v1.0 workflow.07 / 10
Business outcomesEvidence and controls shown together
What we can substantiate today

The heaviest users are close to customers—not inside engineering.

Jianzhi + Insa2,538audited workflow steps in the extracted usage snapshot
Iris + Insa527audited workflow steps, alongside active Zach usage
Iris's support throughput81–115tickets closed per month across the supplied three-month range
Product- and channel-scoped routing
Separate tool allowlists
Read-only diagnostics before writes
Human approval and release authority
Durable tickets, ledgers and audit evidence
Audited steps indicate adoption, not completed tasks or causal productivity improvement.08 / 10
Live demonstrationIris → Zach · Jianzhi → Insa
Observe the handoffs and controls

Two staff members. Two real workflows.

Demo 01 · Iris

Unstructured issue → support ticket

  1. Describe a customer issue naturally.
  2. Watch Zach recover customer and product context.
  3. Review the structured ticket information.
  4. Confirm the durable ticket and next owner.
Public-safe reconstruction of Iris and Zach's ticket workflow
Demo 02 · Jianzhi

Scoped request → technical proposal

  1. Ask inside the configured product channel.
  2. Watch Insa resolve the product lane.
  3. Inspect CodeGraph/DB evidence and proposed scope.
  4. Stop at the human review or PR checkpoint.
Public-safe reconstruction of Jianzhi and Insa's product workflow

Fallback if a live dependency is unavailable: narrate the same checkpoints using the redacted evidence shown above.

Do not use live customer-identifying information in the demonstration.09 / 10
Discussion + follow-upArchitecture · evidence · controls · outcomes
The operating principle

Agents move the work.
People own the outcome.

Questions?

Success IT · Technical briefing · 27 August 202610 / 10
1 / 10