How We Built Our Agentic Architecture for Security and Efficiency

For founders and operators building production AI systems, an agentic architecture improves throughput without expanding risk when each agent has a narrow role, limited tools, lean memory, and human approval gates. At Cressio, that design lets us run real workflows with stronger security, clearer accountability, and less operational drag.

• We built specialized agents instead of one all-powerful assistant.
• Each agent has strict tool permissions and domain boundaries.
• All customer-facing actions stay draft-only until human approval.
• Memory is tiered so active sessions stay focused and cheaper to run.
• Fox handles high-capability execution inside a sandbox with watchdog verification.
• The goal is capacity reclaimed and margin protected, not headcount reduction theater.

What does our agentic architecture look like in production?

At Cressio, I did not want one monolithic AI assistant with access to everything. That would have been easy to demo and hard to trust. Instead, I built a multi-agent system using OpenClaw and Hermes where each agent owns a narrow domain, works inside tool boundaries, and hands off anything customer-facing for explicit human review.

The architecture is organized like a software system, not a personality. Joshua sits at the top as the human operator. Alfred routes commands and manages memory, specialist agents handle bounded workflows, Telegram is the delivery channel, cron runs scheduled jobs in isolated sessions, and Fox takes on heavier execution inside a sandbox that is independently checked by a watchdog.

graph TD
    J[Joshua Human Operator] --> T[Telegram Delivery Channel]
    T --> A[Alfred Main Orchestrator]
    C[Cron Scheduler Jobs] --> A

    A --> E[Email Ops Gmail Airtable]
    A --> P[Proposal Builder Airtable RO]
    A --> O[Content Ops Perplexity Files Exec]
    A --> F[Fox Sandbox Research Code Browser]

    F --> X[Up to Three Child Agents]
    X --> F
    F --> W[Independent Watchdog Verification]
    W -->|Verified| A
    W -->|Mismatch Alert| J

    E --> D{{External Action Needed}}
    P --> D
    O --> D
    F --> D

    D -->|No| R[Return Drafts or Results]
    D -->|Yes| H[HITL Approval Gate]
    H -->|Approved| T
    H -->|Revise| A
    R --> T

That layout exists because we hit real risks and real bottlenecks. A fleet of specialists lets us scope responsibility, contain failure, and improve one workflow without destabilizing the rest of the system.

Why did we reject the “one giant assistant” approach?

One general assistant sounds efficient until it starts mixing inbox context, proposal context, content drafts, credentials, browser automation, and customer-facing actions in one place. When the same system can read everything, call everything, and send everything, convenience turns into risk concentration.

There is also a performance cost. The paper Lost in the Middle: How Language Models Use Long Contexts by Nelson F. Liu and colleagues, published in TACL 2024, found that model performance drops when relevant information is buried in the middle of long contexts. In practice, that means long context windows do not remove the need for better architecture. They simply give you more room to bury the one fact that matters.

Anthropic makes a similar point in Building Effective AI Agents, which recommends simple, composable patterns over forcing one giant autonomous agent to do everything. That matched what we saw firsthand: once we separated concerns, quality improved and monitoring got easier.

How is the Cressio agent fleet actually divided?

Alfred is the orchestrator, not the empire

Alfred is the main orchestrator. It routes commands, manages memory, coordinates the fleet, and decides where work belongs. What Alfred does not do is become an unrestricted super-agent. Its role is coordination, memory discipline, and handoffs.

That distinction matters. By keeping Alfred focused on routing, we preserve visibility into what work was requested, where it went, and which specialist handled it.

Email Ops handles inbox and CRM work only

Email Ops reads inboxes, drafts follow-ups, and syncs CRM data. It has access to Gmail and Airtable because that is what the workflow requires. It cannot execute code, write arbitrary files, or browse the web, which means a mistake inside email operations cannot immediately turn into broader system access.

This is least privilege in the most practical sense. The agent gets enough power to move a workflow forward and no extra power that would enlarge the blast radius.

Proposal Builder is blocked by a Discovery Context Gate

Proposal Builder drafts engagement letters, but only when the minimum discovery context exists. If required partner data is missing, the agent refuses to draft. It has read-only Airtable access and cannot send anything externally, which keeps it grounded in actual intake data rather than polished guesses.

This gate came from a real operational risk. Language models can produce confident writing from incomplete context, so the Discovery Context Gate turns missing information into a hard stop instead of an improv exercise.

Content Ops runs a model-specific publishing pipeline

Content Ops is the specialist for SEO blog production. It uses Perplexity for research, GPT for strategy, and Claude for writing, with file read, file write, and script execution permissions needed to move drafts through the pipeline. It cannot access inboxes or wander into unrelated operational domains.

We route work to the model best suited for the job instead of expecting one model to dominate every stage. The result is better writing quality, better research grounding, and better cost control.

Fox handles heavier execution inside a sandbox

Fox is the Hermes sub-agent that handles multi-step research, code execution, and browser automation. It operates through file-watcher async delegation, can spawn up to three child agents, and cannot modify core identity files. Those limits are intentional because Fox has the most operational reach in the system.

We also do not trust Fox to grade its own homework. A watchdog cron job independently verifies Fox reports against actual system state every six hours.

Which security patterns mattered most?

Least-privilege tool sandboxing

Every agent gets only the tools it needs. That is standard security engineering, but it becomes non-negotiable with AI agents because prompt attacks can try to redirect behavior through available tools. The OWASP Top 10 for LLM Applications and GenAI (2025) lists LLM01:2025 Prompt Injection as the top risk and LLM06:2025 Excessive Agency as another major risk.

The takeaway is simple: prompt discipline helps, but architecture does the real containment work. If an agent cannot reach a tool, it cannot misuse that tool. Boundaries turn a model mistake into a local issue instead of a system-wide incident.

Draft-only external actions with HITL approval

No agent in this architecture is allowed to send emails, publish blog posts, or deliver proposals without my explicit approval. We use a draft-only pattern for anything customer-facing because the cost of a wrong external action is higher than the cost of a short review step. In practice, that is mandatory code review for business operations.

This approach aligns with broader governance guidance. NIST AI RMF 1.0 and the NIST Generative AI Profile both emphasize defined human oversight, clear roles, and monitoring for higher-impact AI systems. Gartner warned in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027 because of rising costs, unclear business value, or inadequate risk controls.

Workspace isolation between agents

Our agents do not freely read each other’s files. That keeps contexts clean, limits accidental leakage, and makes audit trails easier to understand. Workspace isolation also improves reasoning quality because each agent sees the subset of information relevant to its job instead of a noisy pile of cross-functional material.

This is where security and efficiency reinforce each other. The same boundary that protects sensitive information also keeps the active prompt smaller and more relevant.

Encrypted credentials with a modern work factor

Credentials are stored with AES-256 Fernet encryption, the key derivation uses PBKDF2HMAC at 480,000 iterations, and the master password is retrieved from macOS Keychain. That is not security theater. It is a practical way to avoid casual credential sprawl inside automation systems.

The OWASP Password Storage Cheat Sheet recommends at least 310,000 iterations for PBKDF2-HMAC-SHA256 in current guidance. We chose a higher work factor because this system runs in production.

Independent watchdog verification

Fox is useful precisely because it can do more than the other agents. That is why independent verification matters. A watchdog cron job checks Fox’s reports against actual state every six hours rather than trusting the agent’s self-report as final.

NIST’s AI risk management guidance supports the same operating principle: monitoring, logging, and post-deployment evaluation are part of the system, not optional accessories.

The Discovery Context Gate prevents polished guessing

The Proposal Builder’s refusal to draft without minimum partner data is one of the strongest controls in the architecture. Many AI failures in business do not look dramatic. They look polished, reasonable, and slightly wrong because the model filled in missing context with plausible language.

The Discovery Context Gate prevents that. If the required data is missing, the system stops. No inference. No guessing. No proposal drafted on incomplete discovery.

Which efficiency patterns reduced the most operational drag?

Wayne Protocol model routing

We route work by what each model is actually good at. Claude handles writing because tone and readability matter. GPT handles strategy because reasoning structure matters. Perplexity handles research because up-to-date citations matter. The cheapest reliable model handles basic tool-calling because cost discipline matters too.

This is not about brand loyalty. It is about matching the tool to the failure mode.

File-based async delegation instead of blocking RPC chains

Fox work is delegated through files. A task file gets written, Fox picks it up via a file watcher, and the result comes back as a result file. That is less glamorous than a complex orchestration layer, but it gives us a simple, inspectable contract with clean artifacts and less conversational blocking.

If a task stalls, retries, or returns a strange output, we can inspect the artifacts directly instead of reconstructing a hidden chain of agent calls from memory alone.

A four-tier memory system keeps context lean

Our memory system has four layers: hot daily logs, warm PARA knowledge, cold lessons and risks, and distilled long-term memory loaded only in the main session when needed. The goal is not to remember everything at once. The goal is to load the right memory at the right moment.

This directly addresses the long-context problem. Lost in the Middle showed that relevant information buried in the middle of long inputs becomes easier for models to miss. Lean memory is not just cheaper. It is more reliable.

Content vertical rotation removes recurring planning overhead

Inside Content Ops, we run a deterministic 30-day rotation across 11 industry verticals. That removes manual scheduling decisions and keeps the content program balanced. It is a small example of a larger principle: many operations improve when you remove repeat decisions and replace them with explicit logic.

A deterministic rule set is often safer and faster than letting a model improvise every planning choice from scratch.

Cron isolation protects the main session

We run 15 scheduled jobs in isolated sessions so they never pollute the main conversation context. This protects the live operator experience and makes debugging easier because each job has a narrower execution trail.

Again, the pattern is simple: isolate what runs on a schedule from what needs live human judgment. Cleaner context leads to cleaner output.

What did the outside research validate?

I did not start with vendor diagrams and then force my workflows into them. The system design came from Cressio’s real operating needs, but outside research validated the same pressures we were already feeling.

• OWASP Top 10 for LLM Applications and GenAI (2025) names Prompt Injection as LLM01:2025 and Excessive Agency as LLM06:2025, which is a strong case for least privilege and action boundaries.
• NIST AI RMF 1.0 (2023) and the NIST Generative AI Profile (2024) emphasize human oversight, ongoing monitoring, and governance roles for production AI systems.
• Lost in the Middle: How Language Models Use Long Contexts found that performance degrades when relevant information is buried in the middle of long prompts, which supports lean memory and better task decomposition.
• Anthropic’s Building Effective AI Agents recommends simple, composable patterns over prematurely complex agent designs, which matches the specialist-fleet approach we adopted.
• Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, reinforcing the cost of weak controls and unclear value.

How should you design an agentic architecture if you are starting now?

Start with one expensive bottleneck, not a grand theory of autonomous work. Then define the boundaries before you define the prompts: who can read what, who can call what, and which actions require approval.

From there, build specialists before you build sophistication. A narrow agent with good permissions, good logs, and a clear escalation path is usually more useful than an impressive generalist with too much access. Keep context lean, verify high-capability work independently, and measure outcomes in time returned, throughput improved, and errors avoided.

The point is not to say you “use AI.” The point is to architect AI systems the way you architect software systems: with separation of concerns, least privilege, human review, and defense in depth. That is how you reclaim capacity and protect margin without surrendering control.

If you want help designing an agentic architecture that fits your operations, not just a demo environment, book a paid Zoom consultation here. We can map the workflow, the guardrails, and the first production-safe version together.

FAQ

What is an agentic architecture?

An agentic architecture is a production system where multiple AI components have defined roles, tool permissions, memory boundaries, and approval rules instead of one assistant trying to do everything in one context.

Why is least privilege important for AI agents?

Least privilege is important for AI agents because it limits the damage a model can cause if it makes a mistake, follows malicious input, or gains access to a tool it should not control.

Why keep customer-facing actions behind human approval?

Customer-facing actions should stay behind human approval because external mistakes create business, legal, and reputational risk that is usually more expensive than a fast review step.

What problem does a tiered memory system solve?

A tiered memory system solves context overload by keeping active sessions lean, loading only relevant information, and reducing the chance that important details get buried inside long prompts.

Why does independent watchdog verification matter?

Independent watchdog verification matters because a powerful agent should not be the only source of truth about its own actions, especially when it can execute code or automate multi-step workflows.

What should a business automate first with this approach?

A business should automate the first workflow where the bottleneck is obvious, the inputs are clear, the approval boundary is clear, and the result can be measured in time saved, speed, or errors reduced.