OwnFramework Agent — private agent setup on infrastructure you own
A governed private-agent environment, configured on infrastructure the customer owns. Foundation is the environment itself. Launch adds one approved standard workflow pack. They are alternative standard purchase choices. Start with a free eligibility check.
Read the FAQ · Not sure what you need? Start with a Workflow Review.
Confirm the standard envelope: customer-owned supported Linux VPS / cloud, supported runtime, no migration, no multi-node, no custom workflow logic, no regulated workload.
Foundation delivers the governed environment. Launch is Foundation plus one standard workflow pack. They are alternatives, not a mandatory sequence.
Runtime, governance, review surface, and (Launch only) one approved standard workflow pack loaded with sanitized test data.
Sensitive, customer-facing, money, payroll, tax, legal, and irreversible actions still require explicit owner approval.
Decision stays with youFoundation: 7-day setup-defect window. Launch: 14-day support window. Ongoing care is a separate signed agreement.
What it is
OwnFramework Agent is the standardized product path for business owners who already know they want the supported private-agent outcome. We confirm standard eligibility, recommend the right deployment, and configure the environment. Foundation delivers the environment itself. Launch is Foundation plus one approved standard workflow pack.
Two standard products
Foundation delivers the governed private-agent environment itself. Launch is Foundation plus one approved standard workflow pack, configured and proven. They are alternative standard purchase choices. You choose Foundation or Launch based on whether you need just the environment or the environment plus one approved standard workflow pack. A new Launch customer does not pay for both. The customer owns the VPS / cloud account, the model / API provider account, and every credential. VPS, cloud, model API, third-party software, and hardware costs are separate and paid directly by the customer. No checkout. No Buy button.
The governed private-agent infrastructure itself, on a customer-owned supported Linux VPS / cloud VM.
Everything in Foundation, plus one approved standard workflow pack, configured and proven with sanitized test data before any real data is touched.
What you receive
The common deliverable is a governed private-agent environment, on a customer-owned supported Linux VPS / cloud VM, under human approval. Launch additionally configures and proves one approved standard workflow pack. Foundation does not include a workflow pack by default.
A controlled workspace the customer owns, on a customer-owned supported Linux VPS / cloud VM. Not a shared service, not a black box.
A clean place where the owner sees review packets, drafts, and what the agent prepared before anything moves forward.
Help choosing and configuring the supported model and provider that fits the workflow. No vendor lock-in, no hidden costs baked into the agent.
Sensitive, customer-facing, money, payroll, tax, legal, and irreversible actions all require explicit owner approval. No silent sends. No autonomous claims.
The founding pack example is the Contractor Follow-Up Pack, configured and proven with sanitized data before any real data is touched. Foundation does not include a workflow pack by default.
Foundation: 7-day setup-defect window. Launch: 14-day support window. There is no universal 30-day Agent support window. Ongoing care is a separate signed agreement.
Who pays for what
The standard default is that the customer owns and pays the providers directly. OwnFramework helps you select, configure, and document the environment, but the customer can always revoke access.
VPS / cloud, model / API usage, domains / DNS, email / SMS, CRM / SaaS subscriptions, storage / backup provider, paid connectors, and every credential.
Setup labor, configuration, governance design, verification, handoff, and contracted support within scope. OwnFramework does not bundle infrastructure or markup provider fees by default.
When standard does not fit
Requests that fall outside the standard envelope are not stretched into Foundation or Launch. They are scoped and quoted separately so the standard price stays honest.
Moving an existing live system onto a new environment is a custom migration, not a Foundation or Launch envelope.
Local or hybrid deployments that the workflow genuinely requires are a separate scope. They are not one of the two standard products.
Multi-node architecture or unusual networking assumptions do not fit the standard envelope.
Custom business rules, custom integrations, or new connectors beyond a single standard pack are not a standard product.
Workloads requiring custom controls (regulated data, sensitive categories, bank / payroll / tax / legal actions) are not a standard product.
To a focused Working Session, a Workflow Automation Audit & Blueprint, or a Custom Automation Build. The standardized SKUs are not stretched.
Care and support
After Foundation or Launch, ongoing care is a separate signed agreement. None of the three tiers is unlimited, 24/7, or automatic after a build.
Keep one already-delivered supported system healthy. Maintenance, dependency / runtime upkeep, configured backup / recovery verification, and bounded operational support. Unused service capacity does not roll over.
System Care plus limited maintenance of an existing approved automation. Small configuration corrections and limited small workflow adjustments. Unused service capacity does not roll over.
More proactive ongoing operations and improvements for an explicitly defined scope. Monitoring, prioritized incident response, operational review, modest improvements, planned optimization. Scope and operating responsibilities are defined by its signed SOW. Unused service capacity does not roll over.
No 24/7 emergency support. No unlimited support. Unused service capacity does not roll over across the recurring-care tiers. No “you become the local IT contact on retainer.”
Any scoped, time-bound credential the engagement requires is documented in the access plan and can be rotated by the customer following that plan.
Cancellation / offboarding terms (notice period, runbook transfer, credential rotation, and post-offboarding responsibilities) are defined in the signed recurring-service SOW. There is no universal cancellation term across all three tiers.
FAQ
These answers preserve the boundaries: customer-owned infrastructure, no credentials through public forms, human approval for consequential sends, scoped support, no 24/7 promise.
The standard envelope for Foundation or Launch is a customer-owned supported Linux VPS / cloud VM. That is what OwnFramework configures against. A local or hybrid deployment that the workflow genuinely needs is a separate scope, not one of the two standard products.
No. Foundation and Launch do not require a paid Audit when the request fits the standard envelope. A free eligibility check determines whether the standard products apply. A Workflow Automation Audit & Blueprint is the right engagement when the problem or scope is unclear.
Foundation delivers the governed private-agent environment itself (runtime, supported model / provider configuration, governance / review surface, security baseline, health verification, handoff) with a 7-day setup-defect window. Launch is Foundation plus one approved standard workflow pack, configured and proven with sanitized data, with a 14-day support window. They are separate standard purchase choices. Launch already includes Foundation.
Existing server migration, local / hybrid dependency, multi-node architecture, unusual networking, custom workflow logic, heavy / custom external integration, and regulated / sensitive workloads are not Foundation or Launch. They route to a focused Working Session, a Workflow Automation Audit & Blueprint, or a Custom Automation Build.
You do. The customer owns the VPS / cloud account, the model / API provider account, the hardware, and every credential. OwnFramework helps you select, configure, and document the environment, but the customer pays the providers directly. OwnFramework does not bundle infrastructure or mark up provider fees by default.
No. OwnFramework does not sell hardware, SKUs, or boxes. The customer owns the hardware or cloud account. There is no hardware SKU, store, or checkout.
No customer-facing message is sent without explicit owner approval. The agent prepares drafts and review packets. The owner reviews and approves. Sending, customer-facing action, pricing, discount, scope, money, payroll, tax, and legal decisions all stay approval-gated unless separately scoped.
Foundation has its 7-day setup-defect window. Launch has its 14-day support window. Neither rolls into a free ongoing support relationship. Ongoing care is a separate signed agreement: System Care, Automation Care, or Managed Automation Partner (with scope and capacity envelope defined by its signed SOW). Unused service capacity does not roll over across the recurring-care tiers. Cancellation and offboarding terms are defined in the signed SOW for each tier.
No credentials are exchanged through any public form. If a scoped, time-bound credential is needed later, it lives behind a written access plan in the signed engagement letter and follows the rotation / revocation steps documented in that plan. OwnFramework does not hold master passwords, banking credentials, OAuth tokens, or production system credentials.
Email [email protected] with the subject “OwnFramework Private Agent eligibility check.” OwnFramework confirms the standard envelope (customer-owned supported Linux VPS / cloud, supported runtime, no migration, no multi-node, no custom workflow logic, no regulated workload) and then routes the request to Foundation or Launch. If the request does not fit, it routes to a Working Session, a Workflow Audit, or a Custom Automation Build.
Ready when you are
Email OwnFramework to confirm whether Foundation or Launch fits. If it does not, we will tell you and route you to the right next engagement. OwnFramework Agent is a setup engagement, not a checkout, so there is no order form on this page.
