Agentic Automation Canvas (AAC)

Updated 5 July 2026

Agentic Automation Canvas (AAC) is a structured framework that organizes agentic AI projects by integrating project scope, user value, developer feasibility, staged governance, data sensitivity, and outcomes.
AAC employs a semantic web-compatible metadata schema with controlled vocabularies and ontology mappings to ensure machine interoperability and real-time client-side validation.
AAC enables measurable benefit modeling and feasibility assessment, supporting FAIR-compliant exports and transparent, prospective governance of complex agentic automation projects.

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Bandara et al., 27 Jan 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Jang et al., 2 May 2026).

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 (Lobentanzer, 16 Feb 2026).

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 (Lobentanzer, 16 Feb 2026).

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.

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 (Lobentanzer, 16 Feb 2026).

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 (Bandara et al., 27 Jan 2026).

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 (Murad et al., 20 Sep 2025). 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 (Wadinambiarachchi et al., 25 Sep 2025).

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 (Li et al., 13 Oct 2025).

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 (Lobentanzer, 16 Feb 2026).

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.