Repository navigation
Deliver reusable Agentic Engineer definitions through canonical sources #51
Description
🤖 Generated by the Agentic Engineer
Part of #38.
Product direction
Provide one reusable Agentic Engineer definition that portfolios can consume through supported native tools. The plugin owns portable roles, resources and contracts; provenance-recorded skill upstreams own the generic procedures. A consuming repository supplies portfolio, authority, trust, cadence, memory, channels and deployment-specific safeguards.
This boundary lets a reviewed improvement reach each consumer without requiring another local fork of the same behavior. A draft is the delivery checkpoint; promotion and merge follow the consuming contract's genuine-readiness and trust rules.
Future paid subscription product
Maintainer direction recorded on 2026-10-09: package the Devantler Tech agent setup as a reusable commercial solution and require a paid subscription to use that packaged offering. The setup is becoming a competitive advantage, so its proprietary know-how and ongoing improvements need an explicit protection and commercialization strategy.
This is future roadmap work, not authorization to interrupt the business-site/client-portal delivery, activate billing, enroll in paid services, change repository visibility, or alter existing licenses now. Keep this epic in Icebox until its commercial work is refined and prioritized with capacity available.
Proposed direction
- Offer a supported, versioned package with reproducible onboarding, configuration, updates and recovery rather than distributing a copy of a personal workspace.
- Decide which parts constitute the paid product, which remain reusable public foundations, and which proprietary orchestration or operational knowledge must remain private. Public planning must not expose confidential runtime configuration, credentials or customer material.
- Evaluate managed-service and licensed self-hosted delivery against onboarding effort, protection of the differentiating IP, customer control, operational burden and support cost. Do not assume that a public source bundle alone can enforce subscription access.
- Require subscription entitlement for the paid offering, with authenticated access, renewal, cancellation, expiry and a defined outage/grace policy. Do not use a browser-only payment confirmation as entitlement proof.
- Inventory authorship, contribution rights, existing released licenses and third-party obligations before proposing a commercial license or distribution change. Record what can be commercialized and what remains subject to existing grants; do not assume that a new policy removes rights already granted.
- Propose pricing and included support/update scope with hosting and inference cost assumptions. Decide customer-provided inference versus an authorized managed-inference arrangement; do not assume that personal/native subscriptions can be resold or shared.
- Preserve the current trust, safety, review, signing and privacy boundaries in every distribution model. Commercialization is not permission to weaken the Agentic Engineer's controls.
Future acceptance criteria
- Decompose the commercial work into linked, independently deliverable issues, beginning with a timeboxed packaging, IP/licensing and subscription-model decision.
- Record the target customer, package boundary, managed/self-hosted choice, distribution model and ownership of proprietary components.
- Complete the rights/license inventory and obtain the necessary maintainer approval and specialist review for proposed commercial terms.
- Approve subscription pricing, included usage/support, cost limits and inference-provider permissions before enrollment or launch.
- Deliver and test onboarding, signed/versioned updates, entitlement enforcement and the renewal/cancellation/expiry lifecycle, including failed or ambiguous billing and unavailable entitlement-service cases.
- Verify customer/project isolation and a safe exit/handoff path; subscription loss must not delete customer data or damage customer-owned projects.
- Ship through reviewed merges and verify the actual paid customer path before advertising this as available.
Commercial acceptance is not satisfied by the existing public plugin, an issue update or a local prototype. The original technical convergence work below remains valid and must not be duplicated.
Current baseline
The agentic-engineering plugin supplies the engineer, surveyor and improver roles plus canonical engineering and improvement skills. Reviewed contract validation, source provenance and native adapters ship with it. The flagship monorepo declares a reviewed pin and loaders; its compatibility procedures and temporary surveyor overlay still need convergence.
The remaining native children are monorepo#2363, which owns consumer clause preservation and real runtime/survey parity, and #128, which owns the measured micro-agent experiment. Closed children establish their bounded delivered guards and routing fixes; they do not replace those remaining acceptance results.
Completion criteria
- Portable behavior has one owning source and consuming deployments retain only their configuration and necessary provider deltas.
- The flagship consumer follows the reviewed definition, with every removed clause accounted for and real native behavior verified where applicable.
- Source parity, loaded-runtime proof and experimental outcome evidence remain distinct; a merged definition alone proves no outcome.
- The Evaluate micro-agent decomposition for Agentic Engineer #128 experiment reaches its measured decision under the declared observation and recovery criteria. It does not widen unrelated capabilities or override the consumer's inline-survey requirement.
- Definition evolution uses ordinary validated, reviewed, evaluated delivery and the consumer's normal head-pinned merge mechanics.
Keep this epic open while either remaining native child is open or the future commercial acceptance above remains unfinished. Decompose the commercial scope before implementation; technical child merges do not by themselves deliver the subscription product. Further plugin discovery and improver invocation acceptance remain with #74 and #76.
Metadata
Metadata
Assignees
Labels
Type
Fields
Projects
- StatusShow more project fields🧊 Icebox
Activity
docs(adr): define the Automated AI Engineer plugin boundary (#55)
devantler commentedon Jul 13, 2026
Child-2 progress: the skills half shipped via agent-skills#62 (closed — all three generic skills live), and the plugin-assembly half is now draft PR #63 (2 generalized agents + 3 bundled skills + manifests in parity). Remaining after #63: child 3 — the monorepo consumes the plugin and its AGENTS.md shrinks to the deployment configuration + the five contract sections.
feat: add the automated-ai-engineer plugin (agents+skills bundle per …
devantler commentedon Jul 21, 2026
Decomposed into real sub-issues; two of the three phases were already delivered. This was a
Featuredescribing three children in prose, which links nothing — so the board showed no progressand the queue kept re-selecting an issue that was two-thirds done.
Verified against
maintoday:docs/adr/0002-automated-ai-engineer-plugin-boundary.mdplugins/automated-ai-engineer/v1.0.0 — 3 agents, 4 skillsRetyped to
Epicand linked the remaining phase as a cross-repo sub-issue:devantler-tech/monorepo#2363. The rollup now reads 0/1 rather than empty, and the actionable work
sits on the child where it can be picked up.
Phase 3 is the one that pays for the split: until something consumes the plugin, two copies of the
generic role exist and the half that changes weekly is the half that is duplicated.
[-]feat: extract the generic "Automated AI Engineer" core into a dedicated plugin[/-][+]Deliver reusable Agentic Engineer definitions through canonical sources[/+]chore: agent-claim #51 nonce=51c5542fe600f4bd5a3072df1a9ce73e