Company AI Architecture Review: How to Find the Weakest Layer

A company AI architecture review tests each layer an agent depends on (model, harness, memory, tools, permissions, channels and observability) against real tasks, then names the single layer that explains most of the poor outcomes. Fix that layer first, because improving a strong layer while a weak one stays untouched rarely changes what users experience. The review needs a small team and a sample of real work, not a new platform.

Key takeaways

• An agent is a system of seven layers, and its quality is set by the weakest one, not the most impressive one.
• Start from real failed and successful tasks, then trace each failure to a layer, instead of debating the model in the abstract.
• Change one layer at a time and retest on the same tasks, so you know what actually moved the result.
• Memory, tools and permissions are the usual limits in business settings, and they are cheaper to fix than a model switch.
• Keep a short written record of findings, owners and retest dates so the review becomes a habit and not a one-off.

What does a company AI architecture review actually look at?

It looks at the whole system that turns a request into a result. The model is one part. Around it sit the harness (the code and instructions that run the loop, call the model and handle errors), memory (what the agent knows about your company and past work), tools (what it can read and do in your systems), permissions (what it is allowed to do and who approves), channels (where people reach it) and observability (how you see what happened). If you want the full definitions first, The Seven Layers of Company AI Infrastructure, Explained covers each one.

The model gets blamed first because it is the visible part. When an answer is wrong, people say the AI is not smart enough. Often the model was given stale context, a badly described tool, a permission that blocked the last step, or a channel that dropped the attachment. A review separates these causes so that money and attention go where the limit really is.

The review is also not an audit of compliance or a vendor comparison. It answers one operational question: which layer, if improved, would most improve what this agent does for the business this quarter.

How do you prepare the review?

Preparation decides whether the findings are usable. A review of everything at once produces a long list and no priority. Use this plan and keep it to one agent role.

• Pick one agent in one role, such as a support triage agent or an operations assistant. Reviewing several at once hides patterns.
• Collect a representative sample of recent real tasks, including ones that went well, ones that failed and ones people abandoned. Remove nothing because it is embarrassing.
• Write down what a good outcome looks like for each task type, in terms an operations leader would accept. How to Define Success Criteria for an AI Agent Pilot helps if you have no criteria yet.
• Gather the logs, instructions, tool lists, permission settings and channel configuration for that agent. If you cannot gather something, note that, because it is already a finding about observability or ownership.
• Name one person from the business who knows the work, and one person who knows the systems. The review needs both views in the room.
• Agree in advance that the output is a ranked list of layers with one recommended change, not a redesign.

How do you test each of the seven layers?

Go through the layers in turn, and for each one ask a question you can answer with evidence from your sample. The questions below are a working checklist.

• Model: On the failed tasks, does the agent reason badly even when it has the right facts, the right tools and clear instructions? If the same task succeeds once you hand it the missing context, the model is not the limit.
• Harness: Does the agent lose its place in long tasks, repeat steps, stop early, or fail without retrying a recoverable error? Check how it handles timeouts, partial results, and tasks that run across several sessions.
• Memory: Does the agent know your current policies, product details, customer history and naming conventions, and does it know when its knowledge is out of date? Look for answers that are fluent but wrong about your company, and for context that is stuffed in so heavily that the useful part is buried. Anthropic's guidance on context engineering for agents is a good reference for this layer.
• Tools: Are tool names, descriptions and inputs clear enough that a new colleague could use them correctly? Look for the wrong tool chosen, malformed inputs, vague error messages and tools that return far more data than the task needs. Anthropic's guidance on writing tools for agents describes these failure patterns.
• Permissions: Does the agent have the least access that still lets it finish the job, and is every sensitive action behind an approval you can name? Check for access that is too broad, and also for access that is too narrow, which forces people to paste data in by hand. The OWASP authorization guidance supports the principle of least privilege and deny by default.
• Channels: Do people reach the agent where they already work, and does the context arrive intact (attachments, thread history, who is asking)? Low use is often a channel problem, not an intelligence problem.
• Observability: Can you reconstruct, for any task, what the agent was asked, what it retrieved, which tools it called and what it returned? The OpenTelemetry observability primer explains the traces, metrics and logs that make this possible.

For permissions specifically, a recurring check is easier to sustain than a single deep one. Quarterly AI Agent Permission Review: Steps and Evidence describes how to keep it light.

How do you tell which layer is the real limit?

Symptoms overlap, so use a decision guide and then confirm with a controlled change. Read each line as a pattern in your sample.

• The agent is fluent but wrong about your company: suspect memory first, then retrieval inside the harness.
• The agent knows the right answer but cannot finish the job: suspect tools or permissions.
• The agent starts well and degrades on long or multi-step tasks: suspect the harness and how context is carried between steps.
• The agent is correct but nobody uses it: suspect channels, then trust, then training.
• The agent makes the same kind of mistake repeatedly and nobody noticed for weeks: suspect observability and evaluation, not the model.
• The agent does fine on easy cases and fails on those needing judgment even with full context and clear tools: now the model is a credible limit.

Then run a controlled change. Choose the suspected layer, change only that, and rerun the same sample of tasks. If results improve, you found the limit. If nothing moves, your diagnosis was wrong, and that is useful too. Changing the model, the instructions and the tool set together tells you nothing about which one mattered.

What does a review look like in practice? An illustrative scenario

This scenario is illustrative, not a real client case. A mid-sized distribution company has an agent that drafts replies to supplier questions. Staff say it is unreliable, and leadership is considering a different model.

The review samples recent tasks and traces each failure. Most bad drafts quote an outdated delivery policy, because the agent reads a document that was replaced months ago and nobody owns its refresh. That points at memory. A second group of failures happens when the agent tries to check an order status but its tool returns an unreadable error, so it guesses. That points at tools. A third small group are real judgment errors on unusual disputes, which could be the model.

The team fixes the policy source and assigns an owner, rewrites the order tool so its errors are plain and actionable, and reruns the same sample. Most failures disappear without any model change. The few remaining judgment cases are routed to a person by an approval rule. Leadership now has evidence for where the next effort should go, and the model discussion is postponed with a clear reason.

How does Be Human handle this as a managed service?

Be Human treats the layer review as part of operating an agent, not a separate project. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which gives the review something concrete to measure against. Managed operations then include monitoring, recurring evaluations, integration maintenance, permission review and controlled improvements, so layer findings feed a regular cycle of changes instead of a list that ages. Changes go through an approval step with an owner, and the company keeps control of the agent's identity, memory, channels, tools and permissions. How to Improve an Existing AI Setup: A Step-by-Step Audit covers a similar audit if you prefer to run it yourself.

What should you do after the review?

Turn the findings into a small set of decisions. Choose the one layer with the greatest effect on the outcomes you care about, name an owner and describe the change in one sentence. Write the retest date next to it, using the same sample of tasks so the comparison is fair.

Keep a short record with four fields for each finding: the layer, the evidence from the sample, the change made and the result after retesting. This record is what stops the same debate from returning in three months, and it gives a new owner a reliable history if the person who ran the review moves on.

Repeat the review when something material changes: a new model, a new integration, a new channel, a new set of users, or a new kind of task. Between reviews, watch for early signals such as rising manual corrections, tasks abandoned midway and approvals that people click through without reading. These usually show up before a failure becomes visible to customers.

Finally, resist the urge to fix everything at once. A review that produces one clear, tested improvement is worth more than one that produces a long roadmap nobody can sequence.

Frequently asked questions

How often should we run a company AI architecture review? Run a full pass when an agent first goes live, after any major change to models, tools or channels, and on a regular schedule that fits how fast your work changes. Between full reviews, keep light checks on permissions and failed tasks so problems surface early.

Can we do the review ourselves or do we need outside help? A capable internal team can run it if it has someone who knows the business work and someone who knows the systems, and if it is willing to look at failures honestly. Outside help is most useful when you lack visibility into logs, when ownership of layers is unclear, or when you want a second view of tradeoffs.

Is the model usually the weakest layer? In business settings it is less often the limit than people expect. Missing or stale company knowledge, unclear tools, overly broad or overly narrow permissions and poor visibility into behavior cause many failures that look like model weakness. Test the other layers with real tasks before you pay for a model change.

What if we cannot see what our agent did, so we cannot trace failures? Treat that as the first finding. Without records of requests, retrieved context, tool calls and outputs, every other layer is guesswork, so start by adding that visibility, then run the review on the next sample of tasks.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.