How a Multi-Agent AI Atlas project actually works.

01 / EXECUTIVE SUMMARY

The system is a governed digital team, not one chatbot.

A Multi-Agent AI Atlas implementation takes one defined business workflow and divides it into specialized responsibilities. One component plans the work. Another routes tasks to eligible specialists. Domain agents retrieve approved information, analyze the case, apply business rules, evaluate output quality, test safety conditions, and prepare a recommendation. Protected actions stop at a human authority gate until an accountable person approves them.

The project is designed to make the full process inspectable. A client should be able to answer: What happened? Which agent did it? What information did it use? Which tool was called? What rule allowed it? What evidence supports the result? What uncertainty remains? Who approved the final action?

02 / BUSINESS PROBLEM AND SCOPE

We start with a workflow, not with a model.

Before selecting models or building agents, the project defines one workflow with measurable boundaries. For the Northstar Commerce demonstration, the workflow is customer-service resolution for damage, return, shipment, and low-value refund cases.

Scope definition questions

• What business outcome are we trying to improve?
• What exact workflow will the pilot cover?
• Which systems contain the required evidence?
• Which actions can AI prepare, and which actions require a person?
• What failure would be unacceptable?
• How will quality, speed, cost, and risk be measured?
• Who is accountable for the system after the pilot?

03 / OPERATING MODEL

How the client, Atlas, agents, and human reviewers work together.

The operating model is intentionally different from an autonomous black box. Authority is separated from capability. An agent may be capable of generating a refund request, but the Tool Gateway can still prevent execution until the correct approval state exists.

04 / SYSTEM ARCHITECTURE

The production-shaped architecture separates control, intelligence, tools, and authority.

Client workflow request
        |
        v
+--------------------------+
| F36 CONTROL PLANE        |
| Planner -> Router        |
| Execution -> Critic      |
| Safety -> State          |
+--------------------------+
        |
        +------------------------------+
        |                              |
        v                              v
+--------------------+        +-----------------------+
| Domain Specialists |        | Evidence Specialists  |
| F04 Support        |        | F35 RAG              |
| F102 Compliance   |        | Policy / records     |
+--------------------+        +-----------------------+
        |                              |
        +---------------+--------------+
                        v
               +----------------+
               | TOOL GATEWAY   |
               | auth + scopes  |
               | validation     |
               | audit logging  |
               +----------------+
                        |
          +-------------+--------------+
          |             |              |
          v             v              v
       Zendesk        Shopify         Stripe
          |             |              |
          +-------------+--------------+
                        v
               +----------------+
               | EVALUATION     |
               | F37 quality    |
               | F09 safety     |
               +----------------+
                        |
                        v
               +----------------+
               | HUMAN GATE     |
               +----------------+
                        |
                        v
                approved action

Why this separation matters

The planner does not automatically gain access to payment tools. The retrieval agent does not automatically gain authority to act. The safety layer is not the same component that creates the recommendation. The human decision is stored separately from the model output. This separation reduces hidden coupling and makes the system easier to audit, test, and change.

05 / AGENT RESPONSIBILITIES

Each agent has a bounded job and a reason to exist.

06 / RUNTIME STEP BY STEP

What happens when one real client case enters the system.

1. Intake: The customer request is received with a case identifier. The request is classified into the approved workflow.
2. Plan: F36 creates a task graph. Example tasks include retrieve case, retrieve order, retrieve policy, evaluate eligibility, calculate remedy, assess risk, draft response, and prepare approval package.
3. Route: The Router compares each task against declared specialist capabilities. A task is not sent to a specialist merely because its name sounds relevant.
4. Retrieve evidence: Approved adapters retrieve only the records needed for the case. Every retrieval becomes part of the evidence trail.
5. Domain analysis: The service agent determines the likely resolution and explains which evidence supports it.
6. Compliance review: The proposed resolution is checked against policy thresholds and escalation rules.
7. Quality evaluation: The evaluator checks whether the answer is grounded, complete, internally consistent, and within defined thresholds.
8. Safety review: The safety agent checks prompt injection, requested privileges, suspicious instructions, missing evidence, and other blockers.
9. Human gate: If the case is eligible, the system presents the recommendation, evidence, confidence, warnings, and protected action to an authorized reviewer.
10. Action: Only after approval can the approved tool action execute.
11. Record: The final decision, actor, tool call, result, and telemetry are stored for audit and evaluation.

07 / DATA, TOOLS, AND PERMISSIONS

Agents do not receive blanket access to company systems.

Production integrations are designed around least privilege. Each connector receives only the permissions needed for the approved workflow. Read access and write access are treated differently.

Tool Gateway controls

• Authentication and service identity
• Role and scope validation
• Argument validation
• Allowed tool list per agent
• Read vs write classification
• Protected action classification
• Rate limits and cost controls
• Environment restrictions
• Audit logging
• Approval-state validation before side effects

08 / STATE, MEMORY, AND EVIDENCE

The system needs structured state, not just chat history.

Every run is represented as structured workflow state. This lets the client inspect what happened at each stage and prevents later agents from silently replacing earlier evidence.

What the evidence trail should preserve

• Original request and normalized goal
• Plan and task dependencies
• Routing decisions and eligible specialists
• Tool calls and results
• Retrieved evidence and source identifiers
• Model or agent outputs
• Retries and failed attempts
• Critic findings
• Safety findings
• Evaluation scores
• Approval eligibility
• Human decision and identity
• Final action result

09 / HUMAN AUTHORITY AND SAFETY

Human approval is a policy boundary, not a decorative button.

The project defines protected actions before implementation. A protected action might be issuing money, sending a customer commitment, changing production configuration, modifying a regulated record, or making a high-impact decision.

Examples of automatic blockers

• Required evidence is missing.
• Two data sources conflict and the conflict is unresolved.
• The requested action exceeds a policy threshold.
• The agent requests a tool permission outside its declared scope.
• A prompt injection attempt changes the intended workflow.
• Evaluation quality falls below the acceptance threshold.
• The required human role is not authorized for the action.

10 / EVALUATION AND OBSERVABILITY

A pilot is judged by evidence, not by whether the demo looks impressive.

Before the pilot begins, client and Atlas define an evaluation contract. That contract specifies metrics, test cases, thresholds, escalation behavior, and what counts as failure.

Operational telemetry

Production monitoring should include run volume, latency, error rates, tool failure rates, retry counts, evaluation drift, model version, retrieval failures, safety blocks, approval rates, escalations, cost, and downstream action failures.

11 / FAILURE HANDLING

We design the failure paths before production.

12 / PILOT AND PRODUCTION ROLLOUT

We increase autonomy only when evidence supports it.

Typical go / no-go evidence

• Acceptance tests pass at the agreed threshold.
• Adversarial cases are contained.
• Rollback and incident procedures are tested.
• Tool permissions match the approved design.
• Client owners know how to pause the system.
• Human review responsibilities are assigned.
• Monitoring and alerting are active.
• Business value exceeds projected operating cost under realistic assumptions.

13 / CLIENT DELIVERABLES AND RESPONSIBILITIES

What the client receives, and what we need from the client.

14 / SECURITY AND PRIVACY MODEL

Production credentials, client data, and write actions belong behind a secure backend.

The public Atlas demo runs in the browser with synthetic data. A production client deployment should place secrets, model credentials, enterprise connectors, state storage, and protected actions behind server-side controls.

Browser / Client UI
        |
        v
Authenticated Project API
        |
        +--> Orchestrator service
        +--> Model gateway
        +--> Retrieval service
        +--> Tool gateway
        +--> Evaluation service
        +--> Audit / event store
        +--> Approval service
        |
        v
Approved enterprise systems

Production control expectations

• Encryption in transit and at rest where applicable
• Secret management outside the browser and source repository
• Service identities and least-privilege access
• Environment separation between development, staging, and production
• Client-specific data retention policy
• Audit logs for protected actions
• Access review and revocation procedures
• Incident response and rollback procedures
• Model and prompt version tracking
• Dependency and connector change control

Specific regulatory or contractual controls depend on the client, workflow, industry, jurisdiction, and data involved. The project documentation records those requirements rather than assuming one universal compliance profile.

15 / EXAMPLE CASE WALKTHROUGH

Example: damaged order and shipping-fee refund.

Customer request: “My package arrived late and one item is damaged. Can you replace it and refund the delivery fee?”

1. The intake agent creates case objective: verify damage, order, shipment, and refund eligibility.
2. F36 decomposes the goal into retrieval, policy, analysis, compliance, evaluation, and approval tasks.
3. F35 retrieves the Zendesk case, Shopify order, shipment status, and the current refund policy.
4. F04 determines that the item is eligible for replacement and that the delivery fee can be refunded under the cited policy.
5. F102 checks the dollar amount, policy version, and whether any exception requires escalation.
6. F37 evaluates whether the recommendation is grounded in the retrieved records and whether material facts are missing.
7. F09 checks whether the customer message contains instructions attempting to influence internal tools or override policy.
8. F36 compiles an approval package: recommended action, amount, evidence sources, confidence, evaluation result, and safety result.
9. The authorized reviewer approves or rejects the protected refund action.
10. If approved, the Tool Gateway validates approval state and executes the permitted refund call.
11. The system verifies the result and records the final action.

16 / DEMO VS PRODUCTION

The public demo shows the operating model without pretending to be a live client deployment.

17 / FAQ

Questions a client should ask before approving a project.

Why use multiple agents instead of one strong model?

Not every workflow needs multiple agents. We use separate agents when task decomposition, different permissions, specialist capabilities, independent review, retry behavior, or explicit authority boundaries create measurable value. If one bounded component is sufficient, the architecture should remain simpler.

Can the agents act autonomously?

Only within the permissions and action policy defined by the client. During a controlled pilot, consequential actions normally remain human-approved.

What if the AI is uncertain?

Uncertainty can lower evaluation confidence, trigger a missing-evidence state, route to another specialist, or escalate to a person. The system should not convert uncertainty into invented certainty.

Can the system use our internal knowledge base?

Yes, when the source is approved and the retrieval design specifies access, freshness, versioning, and provenance.

How do we know which agent made a decision?

Each event, task, routing decision, tool call, output, blocker, and approval is associated with an actor and run identifier in the workflow state.

What happens if an agent tries to call a tool it should not use?

The Tool Gateway should reject the request before execution and record the denied attempt as a security or policy event.

Who owns the final business decision?

The accountable client organization does. The AI system can support and prepare decisions, but responsibility for protected actions remains with the client-defined authority unless the organization explicitly adopts a different approved operating policy.

18 / GLOSSARY

Plain-language terms used throughout the project.

Agent

A software component assigned a bounded responsibility, often using a model, tools, policies, or retrieval.

Orchestrator

The control layer that plans, routes, coordinates, retries, and records work across agents.

Specialist

An agent or service with declared capabilities for a specific class of task.

Tool

An API, function, database operation, retrieval service, or external system an agent may request through a controlled gateway.

Protected action

An action that requires additional authorization because it has financial, legal, operational, customer, safety, or other consequential impact.

Human authority gate

The point where the system stops until an authorized person reviews and decides.

Evidence

The records, documents, tool results, policy sources, and other approved information supporting a conclusion.

Provenance

Information showing where evidence or an output came from and how it moved through the workflow.

Evaluation contract

The agreed tests, metrics, thresholds, and failure conditions used to judge whether the system is acceptable.

Shadow mode

A production-like run where the AI observes and recommends but cannot affect the real process.

Least privilege

Giving each component only the minimum permissions needed for its assigned work.

Rollback

The defined process for returning to a known safe operating state if a release or change fails.