Straight answers for architects, engineers and buyers.

Connected sources such as CRM, mailbox, documents, calendar and tasks feed focused agents looking for specific misses: a commitment with no follow-through, an obligation buried in a document, a deal that went cold, or a task that has no owner.

The model proposes. AEGIS attaches source evidence. A human approves or rejects the catch before it becomes action or durable memory.

Every proposed catch carries its evidence and provenance, so a reviewer can dismiss weak signals quickly. Recurring checks harden into reusable skills, reducing repeated model calls and improving consistency.

Honest status: tuning the noise floor on broad email history is still active hardening. We prefer proposal-only pilots with measured false-positive review instead of claiming it is universally solved.

In the shared production deployment, each tenant's business data is held in its own PostgreSQL schema, with route-level tenant scoping, role-based access and audit surfaces. Tenant documents, memory and operational data are held behind tenant boundaries, and source access is least-privilege.

The Microsoft 365 connector path is read-only for pilot use, scoped through customer-controlled permissions.

Today AEGIS runs as multi-tenant SaaS in production. The architecture also supports a private deployment path with bring-your-own keys and client-infrastructure residency.

Honest status: Dockerized/deployable architecture is live. Verified client/on-prem deployment remains claim-grade pending until fresh-environment install, migration, backup/restore, LiteLLM route, BYO-key and optional local-model verification pass end to end.

AEGIS is five horizontal layers: Interface, Orchestration, Workers, Memory and Evidence. Two primitives cross every layer: Entity Graph and Governance.

The important boundary is evidence versus accepted memory. CRM, email and document records remain evidence until a human approves a catch or memory promotion. Governance covers source grants, skill grants, model policy, budget posture, audit and the human gate.

The usual first-scope sources are broader than CRM: native AEGIS CRM, HubSpot or another configured external CRM, mailbox/email history, selected Microsoft 365 or Gmail/IMAP paths, Google Drive or uploaded documents, KB material, notes, calendar/tasks, Omni/session context, Memoria and Catch Ledger records.

What changes by pilot is not the architecture but the permission boundary. We separate source evidence from accepted memory and from write-back. For a serious pilot, the source list should be explicit: which systems are read-only, which are out of scope, which can create pending approvals, and which remain unavailable.

Retrieval, analysis, catch generation, drafting and proposal can run agentically inside the configured tenant boundary. External writes, durable Memoria promotion and consequential actions are approval-gated.

This is why the demo path matters: source-backed catch, evidence, approve or reject, Memoria only after approval, then audit. The human gate is a system boundary, not a presentation preference.

There are three separate controls. Per-agent monthly budgets hard-gate direct tasks. Tenant spend caps alert operators as a soft-stop. Model policy selects allowed model aliases by tenant tier and intent before the provider call.

Current status: the resolver and reconciled LiteLLM chain are deployed. Free and trial tenants cannot terminal-fall into premium GPT-4o-class spend; paid tiers use funded aliases with premium quota controls. Remaining hardening is UI surfacing for structured failure metadata and continued migration of legacy call sites.

AEGIS treats idempotency as a system property, not a single retry flag. Incoming events carry stable identifiers where the source provides them, processing is recorded against those identifiers, and work is only treated as complete when it reaches a terminal outcome: created, updated, explicitly skipped, or failed with the operator notified.

For business objects, handlers are designed to resolve before they create: contacts are matched before new records are added, open opportunities are updated instead of duplicated where the same person or source signal is already known, and consequential writes remain approval-gated. Every accepted action leaves an audit trail, so duplicate prevention is both enforced and reviewable.

Under NDA, we can walk through the private delivery mechanics: queueing and retry boundaries, terminal-state records, connector-specific source keys, duplicate-write tests, and the failure modes we deliberately test during a pilot.

AEGIS uses an app-level model-policy resolver plus LiteLLM. Free/trial paths stay on free or local-capable providers such as Groq, Gemini Flash or Ollama-backed routes. Paid plans can use OpenRouter mini or capped premium GPT-4o-class aliases where the tenant tier and intent allow it.

This keeps providers swappable without letting fallback chains cross entitlement boundaries.

Account-level and tenant-level erasure are live. Subject-level erasure inside a live tenant is the next privacy primitive under verification, deliberately before broad customer PII ingestion.

Start with the public architecture flow, AEGIS Framework, Enterprise IT runbook, Tech Stack, Security page and this evaluator Q&A. The private schematic, deployment checklist and customer-specific control matrix are handled under NDA.

Connected CRMs remain systems of record. AEGIS reads provider records as source-backed external evidence, points reviewers back to the exact provider record, and can use that evidence in Omni, Telegram, Opportunity Radar and the Catch Ledger.

HubSpot is the first live proof of this pattern. Importing into native AEGIS CRM or writing back to the provider is deliberately a separate, explicit, human-gated flow.

Standalone Omni is the same governed Omni command surface exposed as a compact web app for logged-in tenants, with dashboard context, Catch Ledger, pending actions, CRM/entity/document views and handoff into /os. It is also the web surface wrapped by AEGIS Guardian on Windows.

Honest status: the main Standalone-depth slices are live. The Windows Guardian pilot installer is validated; signing, signed auto-update, Chrome extension packaging, richer export/report controls and deeper real-use polish remain next.

The Boardroom is the approval loop made deliberate: relevant agents deliberate a topic over rounds, cast structured votes, and produce a synthesis — with source/KB context attached — for a human to accept, edit or veto. It is how multi-agent reasoning becomes a reviewable decision instead of silent action.

Honest status: human-initiated Boardroom sessions are live. Human-configured automatic Boardroom starts are also live for native CRM stage triggers: when a lead enters a configured stage, AEGIS can open a deal-strategy Boardroom, run the agent debate, send the synthesis to Telegram, and ask the human to execute actions or archive. The system may start the deliberation from a rule the human configured; execution still waits for the human decision.

The broader proactive-partner trajectory — agents independently deciding which motions deserve a Boardroom without a configured trigger — remains roadmap, and never bypasses the human gate.

No. Estate-wide agent transformation is not our claim. AEGIS works one layer down: day-to-day business operations, the seams between tools, and a fast proof on real workflows.

The system is agentic underneath, but the product is vigilance: what got missed, why it matters, where the evidence is, and who approved it.

Because expensive misses often do not page anyone. A CRM, mailbox, document repository and calendar can all be correct in isolation while the business still misses the commitment between them.

AEGIS makes those misses visible with evidence and turns accepted catches into reusable memory.

AEGIS can act as a pre-checker on scope, an in-flight promise-versus-evidence view, and an acceptance record for commitments. We frame that as a bounded direction for pilots, not a finished universal delivery platform.

Our own agents are contract-bound, human-gated, least-privilege and auditable. That is why AEGIS can credibly sit as an independent vigilance layer: it is not allowed to silently turn model output into action or durable memory.

Yes, if the pilot is bounded. The right first step is one contained workflow, controlled sources, proposal-only mode, and a weekly Catch Ledger review with business and IT owners.

We will not say yes to an estate-wide program if the evidence says the correct move is a focused proof.

A short operating record: caught misses, false positives, time saved, approval quality, source evidence, and what should harden into reusable skills. The artifact is legible to business owners and technical reviewers.

The best artifact is not a generic benchmark. It is an operating record from a bounded workflow: accepted catches, dismissed catches, source-evidence quality, approval/rejection trail, avoided missed follow-ups and cost per accepted outcome.

That is where AEGIS should be evaluated: did it catch something material, did it show the evidence, did a human accept it, and did the accepted memory improve the next run?