---
title: Agentic Automation Canvas (AAC)
url: https://www.emergentmind.com/topics/agentic-automation-canvas-aac
type: topic
---

# Agentic Automation Canvas (AAC)

The **Agentic Automation Canvas (AAC)** is a structured framework for the prospective design of agentic AI projects and a tool for communication between users and developers. It is intended for systems that can plan, reason, and execute multi-step tasks with limited human oversight, and it organizes an automation project across six dimensions: definition and scope; user expectations with quantified benefit metrics; developer feasibility assessments; governance staging; data access and sensitivity; and outcomes. In its published form, AAC is implemented as a semantic web-compatible metadata schema with controlled vocabulary and mappings to established ontologies, and is exposed through a privacy-preserving, fully client-side web application with real-time validation; completed canvases export as FAIR-compliant RO-Crates, yielding versioned, shareable, and machine-interoperable project contracts between users and developers [2602.15090].

## 1. Rationale and conceptual orientation

AAC was introduced in response to a methodological gap in agentic AI project design. The motivating claim is that agentic AI prototypes are being deployed across domains with increasing speed, yet no methodology for their structured design, governance, and prospective evaluation had been established. The framework is therefore positioned not as retrospective documentation, but as a prospective design instrument that helps negotiate what should be automated, how it will be built, what benefits are expected, and what governance conditions must hold before deployment [2602.15090].

The critique of prior documentation practices is specific. **Model Cards** and **Datasheets** are described as useful but primarily retrospective, documenting artifacts after creation rather than shaping project design before development begins. The **NIST AI RMF** is presented as a governance and compliance framework that is not machine-readable and does not integrate directly with data-management or implementation infrastructure. Existing project planning tools are said to leave the user’s desired value and the developer’s technical feasibility insufficiently explicit within the same structure. AAC answers this by providing a single structured, machine-interoperable canvas for the lifecycle from early design through evaluation [2602.15090].

The framework is also grounded in a particular view of agentic automation. Related organizational work argues that the transition to agentic AI is not mainly a model-selection or coding problem, but an organizational redesign problem involving domain understanding, workflow decomposition, human control, and operating-model change. This does not define AAC itself, but it helps explain why AAC emphasizes project scope, user value, technical feasibility, governance, and operational outcomes in a single artifact [2602.10122].

## 2. Core structure: the six dimensions

AAC organizes an agentic automation project into six connected dimensions. The framework treats these dimensions as a prospective design surface rather than a static reporting template [2602.15090].

| Dimension | Main contents | Function |
|---|---|---|
| Definition and scope | Title, description, objectives, development stage, domain classification, keywords, funding, lead organization, value summary | Anchors project purpose |
| User expectations with quantified benefit metrics | Structured requirements, user stories, priorities, unit of work, volume, dependencies, stakeholders, benefit metrics | Makes expected value explicit |
| Developer feasibility assessments | TRL, technical risk, effort estimate, algorithm specifications, tool requirements, model selection, architecture | Records technical realism |
| Governance staging | Lifecycle phases, dates, decision-makers, milestones, KPIs, compliance standards | Creates an auditable governance trail |
| Data access and sensitivity | Format, license, access rights, sensitivity, personal data, DUO terms, persistent identifiers | Represents the data environment |
| Outcomes | Deliverables, publications, evaluation results | Closes the loop between expectations and results |

The **definition and scope** dimension captures what is being automated and why. Its fields include title and description, objectives, development stage as **planning**, **prototype**, or **deployment**, domain classification and keywords, funding information, lead organization, and a project-level value summary comprising a headline value statement and primary value driver. The paper emphasizes that this is not merely descriptive metadata; it makes later expectations and governance decisions interpretable in context.

The **user expectations** dimension is the most distinctive planning layer. It treats expectations as structured requirements with fields such as title, description, user story, priority, status, unit of work definition, monthly volume, dependencies on other requirements, and linked stakeholders. This section binds projected value to concrete requirements rather than leaving value claims informal.

The **developer feasibility**, **governance**, **data**, and **outcome** dimensions serve as counterweights to optimistic automation narratives. Together they make the canvas a co-authored, iterated, and implementation-tied project contract rather than a simple idea-capture worksheet.

## 3. Quantified benefit modeling and feasibility assessment

AAC’s benefit model is designed to make expected value measurable, comparable, and reviewable. The framework defines five benefit types: **time**, **quality**, **risk**, **enablement**, and **cost**. Each metric includes a metric identifier, a label, a direction—**higher**, **lower**, **target**, or **boolean**—an indication of whether the value is an **absolute value** or a **delta**, baseline and expected values that may be numeric, categorical, or binary, an aggregation basis of **per unit**, **per month**, or **one-off**, confidence levels from both user and developer, and free-text assumptions [2602.15090].

For time-related benefits, the model explicitly subtracts human oversight time from gross savings. The paper states the logic in prose: **gross time saved = time previously spent on the task** and **net time benefit = gross time saved − human oversight time**. Oversight can be recorded as **minutes per unit of work** or **minutes per month**. At the project level, benefits are aggregated using **volume-weighted calculations**, allowing frequent tasks to contribute more strongly than infrequent ones. The stated aim is not to prove benefit in advance, but to make the expected value proposition explicit, measurable, and realistic.

AAC balances this user-facing layer with **developer feasibility assessments**. At the project level, the schema records **technology readiness level (TRL)**, overall technical risk, and effort estimate. At the task level, it supports overrides for algorithm specifications, tool requirements, model selection, and implementation architecture. Supported architectural patterns include **simple prompting**, **retrieval-augmented generation**, **fine-tuning**, and **agentic frameworks**. For RAG, the canvas can capture retrieval method, embedding model, and chunking strategy; for fine-tuning, it can record the base model, approach, and dataset; and for agentic frameworks, it can record framework, tools, and orchestration details [2602.15090].

This pairing of benefit quantification and feasibility assessment is central to AAC’s logic. A project may carry ambitious expected benefits while also being assessed as low maturity, high effort, or high risk. AAC is designed to surface that mismatch early rather than after implementation has begun.

## 4. Governance staging, data conditions, and outcome closure

AAC treats governance as a staged process rather than a static checklist. **Governance staging** records lifecycle phases with start and end dates, responsible decision-makers—which may be persons, organizations, or software systems—milestones and KPIs, and compliance standards that apply to each phase. The paper describes this as an **auditable governance trail** because it specifies who has decision authority, when decisions occur, what evidence is needed at each stage, and what standards govern the project [2602.15090].

The **data access and sensitivity** dimension formalizes the project’s data environment. It records dataset metadata including format, license, access rights—**open**, **restricted**, **confidential**, or **highly restricted**—sensitivity level, whether the data include personal data, DUO usage terms, and persistent identifiers. This is particularly relevant for clinical and institutional systems, where a project may involve mixed-access data or privacy-sensitive records. The framework’s contribution here is not merely descriptive; it expresses access constraints in a machine-readable way.

The **outcomes** dimension is the closure mechanism. It records deliverables with type, status, and persistent identifiers; publications with DOIs and author lists; and evaluation results with metrics, methods, and findings. The paper presents this as a way to compare later observations with the benefit expectations specified up front. In this sense, AAC links project design, governance, and evaluation within one versioned structure.

A practical implication, suggested by adjacent work on agentic AI interfaces, is that governance fields in AAC are especially relevant when oversight must be exercised through explanation rather than continuous manual control. That literature argues for **action-process**, **uncertainty**, and **coordination** explanations as autonomy increases, which aligns with AAC’s emphasis on staged decision authority, reviewability, and outcome tracking [2605.01610].

## 5. Semantic-web implementation, RO-Crate export, and client-side application

A major contribution of AAC is that it is not only a form, but also a semantic web-compatible metadata schema. The framework maps its concepts to established standards including **Schema.org**, **W3C DCAT**, **W3C PROV-O**, **P-Plan**, **FRAPO**, and **DUO**. The paper gives concrete mappings: projects use Schema.org types such as `Project`, `ResearchProject`, and `CreativeWork`; people are represented as `schema:Person`; datasets map to `dcat:Dataset`; governance activities are modeled as `prov:Activity`; user requirements are modeled as `p-plan:Step` within a `p-plan:Plan`; funding information uses FRAPO; and data-use restrictions use DUO terms such as `DUO:0000006` and `DUO:0000007` [2602.15090].

The schema also defines controlled term lists for **TRL levels 1–9**, DUO terms, governance stages, risk levels—**low**, **medium**, **high**, **critical**—and functional roles. This controlled vocabulary is important because AAC seeks descriptions that are not only human-readable, but also consistent enough for programmatic comparison, validation, and aggregation.

Completed canvases export as **RO-Crate 1.2 packages**. These include `ro-crate-metadata.json` in JSON-LD, a human-readable `ro-crate-preview.html`, the original `canvas.json`, documentation files, and an `AGENTS.md` file for AI/coding-agent consumption. The export is described as **FAIR-compliant** and shareable, while allowing the crate to remain private, to be shared selectively, or to be published openly in repositories. The inclusion of `AGENTS.md` is notable because it translates the design contract into instructions usable by copilots or LLM-based development agents, making the canvas “AI-ready” in a practical sense [2602.15090].

The web application is **privacy-preserving** and **fully client-side**. Its workflow is explicit: the user opens the browser-based app; fills out the six sections through guided forms; receives **real-time validation** as fields are entered; may import an existing canvas JSON file for iterative editing; and can then export the canvas as an RO-Crate ZIP package. Because the app runs entirely in the browser, no server-side processing occurs and canvas data never leaves the user’s machine. The schema profile is maintained independently of the web app at `w3id.org/aac`, and the implementation stack comprises **Vue.js 3**, **TypeScript**, **Vite**, and **Tailwind CSS**.

## 6. Use cases, related literature, and major distinctions

The paper presents AAC as applicable to diverse settings, including **single-cell bioinformatics**, **clinical research assistants**, **drug target databases**, **patient-facing chatbots**, **research data management**, and **institutional AI coordination**. One concrete example is the **Open Targets** drug-discovery platform: users are drug-discovery experts with biological expertise; they seek conversational access to drug-target associations; expected benefits include **reduced time-to-insight** and **better accessibility for non-computational researchers**; feasibility is assessed for retrieval-augmented generation using a custom MCP server over the Open Targets knowledge graph; risk is described as medium-high; governance includes platform-team validation during prototyping and staged rollout from internal testing to public deployment; and outcomes are intended to be compared back to the original benefit estimates [2602.15090].

AAC also sits within a broader landscape of AAC-adjacent work. A practical guide to organizational transition proposes recurring dimensions that closely resemble canvas components: **business domain and process understanding**, **manual workflow mapping**, **use-case identification and prioritization**, **task decomposition into agent roles**, **workflow orchestration and integration**, **human-in-the-loop control points**, **team and ownership model**, **governance, evaluation, and adaptation**, and **scaling and operational deployment**. This does not constitute AAC as a named framework, but it reinforces the canvas’s emphasis on domain-driven workflow transformation, small cross-functional teams, human orchestration, and workflow-level evaluation [2602.10122].

Other adjacent literature helps interpret specific AAC dimensions. A survey on agentic AI in future computing environments provides deployment alternatives across **cloud**, **edge**, and **on-premises** settings, along with governance and security concerns and taxonomies such as **Reflection Pattern**, **Tool Use Pattern**, **Planning Pattern**, and **Multi-Agent Collaboration (MAC) Pattern**. This suggests that AAC’s feasibility and governance sections can be informed by infrastructure placement, orchestration pattern, and platform choice, even though the survey does not itself define AAC [2509.16676]. Work on future design workflows similarly emphasizes authority distribution, multimodal intent expression through annotations, sketches, tags, and voice, and context-dependent autonomy boundaries; these ideas are particularly relevant when AAC is applied in creative or collaborative settings [2509.20731].

A persistent ambiguity in the literature is terminological rather than conceptual: **AAC** can also denote **Agent Access Control**, a distinct framework for access control in LLM-based agent systems. That work reframes access control as a dynamic, context-aware process of information flow governance, built around **multi-dimensional contextual evaluation**, **adaptive response formulation**, and a dedicated AC reasoning engine. It is not the Agentic Automation Canvas, despite the shared acronym [2510.11108].

The main limitations acknowledged for the Agentic Automation Canvas are also specific. Because the output is a **private-by-design RO-Crate**, sharing and discovery are not automatic; for projects outside the authors’ direct involvement, additional mechanisms are needed to make canvases discoverable and reusable. The paper suggests future integration with **an MCP server registry**, **knowledge-graph framework registries**, and **community research software platforms**. It also does not present a single closed-form optimization equation or formal LaTeX formulation; AAC’s formal content lies instead in its schema design, controlled vocabularies, ontology mappings, and export format [2602.15090].

In sum, the Agentic Automation Canvas defines agentic automation as a prospective, negotiated, and machine-readable design problem. Its distinctive contribution is to combine project scope, quantified user benefits, developer feasibility, staged governance, data access and sensitivity, and outcome tracking within a versioned structure that is simultaneously human-readable, interoperable, and tied to implementation.

Source: https://www.emergentmind.com/topics/agentic-automation-canvas-aac