Business Process Audit: Agent Task Analysis

Introduction

In the previous module, we established the foundational mental models for designing agentic systems. We learned how to define an agent's "job" using the employee model, select an appropriate cognitive architecture, and, crucially, how to enforce its operational boundaries using the Principle of Least Authority (PoLA). We've essentially created a detailed profile for a secure and well-scoped agent "employee."

Now, we shift our focus to Module 3: Designing Agent Information Environments. An employee, no matter how skilled or constrained, cannot function in a vacuum. They need a comprehensive briefing, access to relevant documents, and clarity on their specific tasks. This module is about providing your agent with exactly that.

This lesson addresses the very first step in that process. Our learning outcome is to audit a business process to identify the inputs, context, and knowledge an agent needs to perform a task. This is the core discovery phase of any agentic AI project. For you, as someone aiming to provide these solutions as a service, this auditing skill is the cornerstone of a client engagement. Before you can design a solution, you must deeply and systematically understand the current state of the process you intend to automate.

1. The AI Audit: A Framework for Discovery

The first step in building an agentic workflow is not technical; it's investigative. You need to perform what can be called an "AI Audit" — a structured analysis of a business process to understand its mechanics and identify opportunities for automation. This process involves mapping workflows, interviewing stakeholders, and identifying pain points.

The following video provides an excellent overview of this process from the perspective of an agency that, like you aim to, provides AI solutions to clients. It frames the audit as a core business offering and a critical discovery phase.

2. Step 1: Mapping the "As-Is" Process

With the high-level strategy in mind, let's dive into the specifics of that first stage. The goal is to create a detailed map of the existing business process as it currently operates. This map is your baseline, your source of truth for identifying what an agent will need to know and do.

The article below provides a practical, step-by-step guide to creating this process map.

To gather the information needed for this map, you'll conduct stakeholder interviews and analyze existing documentation. The key is to know what questions to ask and what information to look for. The next video segment provides a practical guide to this information-gathering phase.

Based on these resources, when you audit a process, you are building an inventory of the following elements:

• Tasks & Sub-tasks: The specific actions performed.
• Roles: Who (or what system) performs each task.
• Triggers: What initiates the process or a specific step.
• Inputs: The data, documents, or forms used to perform a task.
• Outputs: The reports, communications, or system updates that result from a task.
• Tools & Systems: The software applications, databases, or APIs involved.
• Decision Points: Moments where logic is applied or a choice is made.
• Required Knowledge: The policies, guidelines, or implicit "tribal knowledge" needed to make decisions correctly.
• Dependencies: How tasks rely on each other.
• Bottlenecks & Pain Points: Where the process is slow, error-prone, or inefficient.

3. Step 2: From Process Map to Agent Requirements

Once you have your detailed "as-is" map, the next step is to analyze it to define the requirements for a potential agentic solution. This involves categorizing tasks and making a critical architectural decision: does this task require an agent's reasoning ability, or can it be handled by simpler, more deterministic automation?

Given your background, you'll recognize the importance of using the simplest effective tool for the job. Applying a costly, probabilistic LLM to a task that can be solved with a deterministic if-then statement is an architectural anti-pattern.

After filtering out the tasks suitable for classic automation, you can focus on those that genuinely require an agent. For these tasks, you'll define the agent's role and the resources it needs—which are the inputs and knowledge you identified in your audit.

4. Example: Auditing a Meeting Follow-up Workflow

Let's ground this with a concrete example. Consider a common business process: post-meeting action item processing.

• As-Is Process: After a client call, a project manager manually reviews the meeting transcript. They identify bugs and feature requests, create corresponding issues in GitHub, and post a summary of the discussion and decisions to a specific Slack channel.

Now, let's audit this process using our framework:

• Inputs:
  • Meeting transcript (unstructured text).
  • List of participants.
  • Project repository name (e.g., acme-corp/project-alpha).
• Required Knowledge:
  • How to distinguish a "bug report" from a "feature request."
  • The correct template/format for a GitHub issue title and body.
  • Which Slack channel is used for project updates.
  • Implicit knowledge about the project to understand the context of the discussion.
• Tools:
  • Zoom/Google Meet (for the transcript).
  • A text editor.
  • GitHub API.
  • Slack API.
• Decision Points:
  • Is this part of the transcript an action item?
  • Is this action item a bug or a feature?
  • Is this summary point important enough to include in the Slack update?
• Outputs:
  • One or more issues in a GitHub repository.
  • A single message posted to a Slack channel.

This audit clearly defines what an agent system would need to replicate this workflow. The following workshop video demonstrates an architecture that does exactly this, showing how the audit's findings translate into system design.

Conclusion

In this lesson, you've learned the structured, repeatable process of auditing a business workflow to discover what an agent needs to function. This is the bridge between a high-level business problem and a concrete agent system design.

Key Takeaways:

• Auditing is a Discovery Process: The "AI Audit" is a systematic investigation to map a business process's tasks, roles, tools, inputs, outputs, and required knowledge.
• Start with the "As-Is" Map: A detailed process map is the foundational document from which all agent requirements are derived.
• Apply the "Rules vs. Reasoning" Filter: A key design decision is to distinguish between tasks that need deterministic automation and those that require an agent's reasoning capabilities.
• The Audit Defines the Agent's "Briefing": The collected inputs, context, and knowledge form the complete set of information an agent needs to perform its designated task.

Preview of the Next Lesson

We have now successfully identified what information our agent needs. The next logical question is how should we structure and provide this information? In the next lesson, we will distinguish between static context (system instructions), dynamic context (retrieved data), and conversational context (user input). This will give us the vocabulary and mental models to design the agent's complete information environment.