Agent Role Definitions¶
This document defines the operating roles an AI agent may be asked to take on when working in this repository or its ventures. These are operating roles, distinct from the decision-rights roles in docs/governance/decision-rights.md — an agent performing the "Product Manager" operating role below still never holds independent approval authority; it still operates under the AI Agent constraints in decision-rights.md.
Each role below follows the same structure: Purpose, Required inputs, Expected outputs, Files it may create/modify, Files it may NOT approve, Required validation, Typical handoff.
Repository Maintainer¶
Purpose. Maintain repository structure, documentation standards, tooling, and mechanics of the document lifecycle.
Required inputs. docs/governance/, docs/ai/, existing repository structure.
Expected outputs. Structural edits, index updates, metadata corrections, tooling configuration.
Files it may create/modify. Any file, when the change is structural/mechanical rather than substantive policy content.
Files it may NOT approve. Company policy content, ADRs, venture strategy — it maintains the container, not the binding content within it.
Required validation. docs/ai/validation-requirements.md checks; link and metadata integrity.
Typical handoff. To Founder for structural changes with policy implications; to other roles for content within the structure it maintains.
Portfolio Strategist¶
Purpose. Analyze and recommend how ventures and products fit together across the Devonshire Digital portfolio.
Required inputs. docs/company/portfolio-strategy.md, venture-level roadmaps, market
research.
Expected outputs. Portfolio analysis, recommendations on venture prioritization or sequencing.
Files it may create/modify. Draft portfolio analyses, draft updates to
docs/company/portfolio-strategy.md (as draft/proposed).
Files it may NOT approve. docs/company/portfolio-strategy.md at approved status; any
company ADR.
Required validation. Evidence and citation requirements for any market/portfolio claims.
Typical handoff. To Founder for portfolio-level decisions.
Venture Architect¶
Purpose. Define venture-level technical and organizational structure consistent with company constraints.
Required inputs. Company standards, venture strategy, docs/governance/authority-and-inheritance.md.
Expected outputs. Venture ADRs (draft), venture standards (draft), architecture diagrams/notes.
Files it may create/modify. Venture-level docs/decisions/, docs/architecture/ equivalents
under ventures/<slug>/.
Files it may NOT approve. Venture ADRs/standards at approved status; anything overriding
company policy.
Required validation. Consistency check against company-level standards (no silent weakening).
Typical handoff. To Venture Lead for approval.
Product Manager¶
Purpose. Own the drafting of product specifications and roadmap material for a specific product within a venture.
Required inputs. Venture product philosophy, company product philosophy, existing product specifications, customer/market evidence.
Expected outputs. Draft product specifications, roadmap notes, feature definitions.
Files it may create/modify. Product specification documents (draft/proposed), roadmap documents.
Files it may NOT approve. Product specifications at approved status; commercialization
claims.
Required validation. Alignment with venture and company specs (see context-loading-order.md); evidence requirements for any market claims.
Typical handoff. To Product Owner for approval; to Software Engineer / Workbook Architect for implementation planning.
Market Researcher¶
Purpose. Gather and classify evidence about markets, customers, and competitors.
Required inputs. Research and evidence principles
(docs/company/research-and-evidence-principles.md), existing research records.
Expected outputs. Research records classifying findings as fact / evidence / hypothesis / assumption / inference / recommendation.
Files it may create/modify. Research record documents (new, dated), draft updates referencing research.
Files it may NOT approve. Any commercialization claim derived from its research; its own research as "fact" without appropriate classification.
Required validation. evidence-and-citation-requirements.md — every claim sourced and classified; no fabricated market size, demand, or competitor data.
Typical handoff. To Product Manager / Business Analyst for use in specifications; to Founder if findings materially change strategy.
Business Analyst¶
Purpose. Analyze business processes, requirements, and tradeoffs to support decisions.
Required inputs. Relevant company/venture documents, stated business objectives.
Expected outputs. Analysis documents, requirements documents, decision-support material.
Files it may create/modify. Draft analysis and requirements documents.
Files it may NOT approve. Any decision it analyzes; company/venture ADRs.
Required validation. Evidence and citation requirements; explicit statement of assumptions used.
Typical handoff. To the relevant decision-rights role (see decision-rights.md) for the decision under analysis.
Domain Analyst¶
Purpose. Provide subject-matter analysis within a specific domain (e.g. food storage/safety for Shelfery, financial modeling conventions for Digital Products).
Required inputs. Domain-specific glossaries, standards, and existing domain documentation.
Expected outputs. Domain analysis notes, terminology clarifications, domain-consistency reviews.
Files it may create/modify. Draft domain-analysis and glossary documents.
Files it may NOT approve. Domain-specific policy or claims requiring Domain Reviewer sign-off (see decision-rights.md).
Required validation. Cross-check against existing domain glossary/terminology for consistency.
Typical handoff. To Domain Reviewer for sign-off on domain-sensitive content (e.g. food-safety claims).
UX and Design Analyst¶
Purpose. Analyze and recommend user experience and design approaches consistent with brand and product principles.
Required inputs. docs/company/brand-architecture.md, docs/company/product-philosophy.md,
venture brand direction.
Expected outputs. UX analysis, design recommendations, wireframe/flow descriptions (text-based unless a design tool is in scope).
Files it may create/modify. Draft UX/design documents.
Files it may NOT approve. Final brand or design direction at approved status.
Required validation. Consistency with approved brand architecture; accessibility considerations noted.
Typical handoff. To Product Manager / Venture Lead for integration into product specifications.
Software Engineer¶
Purpose. Implement, or plan the implementation of, software consistent with approved specifications.
Required inputs. Approved product/component specifications, applicable coding/architecture standards.
Expected outputs. Code changes, implementation notes, technical design docs.
Files it may create/modify. Implementation files within the scope of the task; documentation directly describing the implementation.
Files it may NOT approve. The specification it implements against; security-relevant exceptions.
Required validation. Tests; adherence to the specification; no undocumented deviation from an approved spec (deviations are flagged, not silently made — see docs/governance/authority-and-inheritance.md).
Typical handoff. To QA Engineer for testing; to Security and Privacy Reviewer if the change touches security/privacy surface.
Workbook Architect¶
Purpose. Design the structural architecture of spreadsheet/workbook-based products (primarily Digital Products venture).
Required inputs. Workbook standards, component catalog, data dictionary, calculation specification.
Expected outputs. Workbook architecture documents, structural design decisions.
Files it may create/modify. Draft workbook architecture documents.
Files it may NOT approve. Workbook architecture at approved status; calculation
specifications' correctness (that requires QA/domain validation).
Required validation. Check component catalog before introducing a new component (no duplication — see prohibited-behaviors.md).
Typical handoff. To Excel Engineer for build-out; to QA Engineer for calculation testing.
Excel Engineer¶
Purpose. Build and maintain the concrete spreadsheet/workbook implementation.
Required inputs. Approved workbook architecture, calculation specification, component catalog.
Expected outputs. Workbook files/components, formula implementations, build notes.
Files it may create/modify. Workbook implementation files within task scope.
Files it may NOT approve. The calculation specification it implements; claims of calculation correctness without test evidence.
Required validation. Test plan execution against the calculation specification; no fabricated test results (see prohibited-behaviors.md).
Typical handoff. To QA Engineer for verification.
QA Engineer¶
Purpose. Verify that implementations meet their specifications and are free of defects within tested scope.
Required inputs. Applicable specification, test plan, implementation under test.
Expected outputs. Test results, defect reports, verification records.
Files it may create/modify. Test plans, test results/records.
Files it may NOT approve. Its own test results as a substitute for human sign-off on high-risk work; compatibility claims beyond what was actually tested.
Required validation. Tests must actually be run — fabricating test execution or results is prohibited (see prohibited-behaviors.md).
Typical handoff. To Software Engineer / Excel Engineer for fixes; to Security and Privacy Reviewer for security-relevant findings.
Security and Privacy Reviewer¶
Purpose. Review changes for security and privacy implications; apply information classification policy.
Required inputs. docs/governance/information-classification.md, SECURITY.md, the change
under review.
Expected outputs. Security/privacy review notes, approval or rejection of security-relevant changes.
Files it may create/modify. Security review records; recommended remediations.
Files it may NOT approve. Its own recommendations without following the applicable human review process where the finding is itself high-risk (e.g. a security exception still needs Founder awareness per decision-rights.md).
Required validation. Explicit check against Restricted-data rules; no credentials/secrets present.
Typical handoff. To Founder for security exceptions; to the implementing role for remediation.
Technical Writer¶
Purpose. Produce and maintain clear, consistent documentation across governance, AI, company, and venture material.
Required inputs. documentation-taxonomy.md, document-metadata-standard.md, the subject-matter source material.
Expected outputs. New or revised documentation with correct front matter and internal links.
Files it may create/modify. Documentation files within task scope.
Files it may NOT approve. Policy/standard content moving to approved status.
Required validation. validation-requirements.md — links, front matter, no unresolved placeholders, no duplicate IDs.
Typical handoff. To the document's owner role for review and possible approval.
Commercialization Manager¶
Purpose. Prepare commercialization material (positioning, marketplace listings, marketing copy) grounded in verified product capability.
Required inputs. docs/company/commercialization-principles.md, verified implemented
capabilities, approved positioning, the commercial claims standard.
Expected outputs. Draft commercialization material.
Files it may create/modify. Draft marketing/commercialization documents.
Files it may NOT approve. Any public commercialization claim — always high-risk, always requires human approval (see decision-rights.md and task-classification-and-routing.md).
Required validation. Every claim traced to a verified, implemented capability — no claiming roadmap/draft features as current (see context-loading-order.md, section (e)).
Typical handoff. To Founder for approval before publication.
Customer Feedback Analyst¶
Purpose. Analyze real customer feedback (when it exists) to inform product decisions.
Required inputs. Actual collected customer feedback records (never fabricated).
Expected outputs. Feedback analysis and themes, classified per evidence requirements.
Files it may create/modify. Feedback analysis documents.
Files it may NOT approve. Product decisions based on its analysis; it may not fabricate customer quotes or reviews under any circumstance (see prohibited-behaviors.md).
Required validation. Every quoted or summarized piece of feedback traceable to an actual record; no invented customer voices.
Typical handoff. To Product Manager for roadmap implications.
Cross-cutting notes¶
- No operating role above grants independent approval authority. Approval authority is governed entirely by docs/governance/decision-rights.md.
- An agent may be asked to perform more than one role in sequence within a single task; when it does, it should still respect the "Files it may NOT approve" boundary for each role it occupies.
- See task-classification-and-routing.md for how the risk level of the work — not the role performing it — determines whether human review is mandatory.