Terms of service

The service

Inlay provides a visual graph, an agent execution backend, and SDK interfaces for builders creating agent products. Depending on configuration, those products can use tools, retrieval, state and memory, schedules, usage metering, and customer billing features. Builders supply their own interface, product logic, sign-in, and user authorization.

Private-beta access

Access requests are reviewed manually and onboarding is not automatic. Submitting a request does not guarantee an invitation, a start date, or access to every feature. Access scope, limits, and commercial terms need to be discussed during onboarding. The beta is not presented here as free or unrestricted use.

Pending review: eligibility requirements, the account agreement process, and the grounds and procedures for suspension or termination.

Your application and credentials

• Authenticate and authorize your users before your server mints Inlay sessions. Use accurate user and group claims, appropriate agent scopes, and the limits your product needs.
• Keep secret keys and management operations out of browser code. Protect session tokens too. Use vault references for supported connector credentials rather than embedding secrets in prompts, graph definitions, or public outputs.
• Review the permissions granted to external connectors and to client-tool handlers in your own application. Treat suspected credential exposure as a security issue, not as harmless because the credential expires.

Agents, data, and outputs

• Have the necessary rights and permissions for submitted prompts, retrieval documents and metadata, memory values, credentials, scheduled tasks, and data sent to external tools or models.
• Choose user and agent state scopes, retrieval permissions, and public output visibility deliberately. A private credential does not make a model's answers or a tool's returned data private.
• Review generated content and authorize consequential actions in your product. Model output can be incorrect; schema validation does not establish factual accuracy or suitability for a user.

Pending review: ownership and licensing provisions, the permission needed to process submitted data, and the treatment of generated outputs in light of applicable law and third-party terms. This draft does not promise exclusive ownership of every model output.

Scheduled work and external actions

Schedules start runs as a specified end user and can invoke tools without an open browser. Use agents that do not depend on browser input, account for repeat execution, and design external side effects accordingly. Current delivery and failure-handling limits are described in the schedules guide.

A successful model or tool response is not a guarantee that an external action was correct, unique, or appropriate. Your product needs its own validation, approval, and recovery decisions.

Proposed acceptable-use requirements

• Do not use the service for unlawful, abusive, or deceptive activity.
• Do not access other tenants' data, bypass authorization or usage controls, or use credentials without permission.
• Do not direct agents or tools to retrieve or disclose data your users are not authorized to access.
• Follow the applicable policies of the model, tool, and payment providers your product uses.

Models and third-party services

Inlay connects to configured OpenAI-compatible providers. Available models and capabilities vary by deployment and provider. There is no promise of access to every model, compatibility with every provider feature, or uninterrupted third-party availability.

External services receive the data sent to them. Their data handling, retention, and training terms are not replaced by this draft. Review the providers and configuration relevant to your workload, alongside the draft privacy policy.

Platform pricing and customer billing

Launch rates are pending. Public prices, included allowances, usage rates, overage rules, and any customer-billing fees have not been approved. Metering a run or exposing billing APIs does not establish a commercial rate.

Your own users' plans and credit purchases are separate from your charges for using Inlay. Hosted subscription and top-up flows require a connected Stripe account with charges enabled; subscriptions also require a published plan. Plan changes are operator-side today, and invoice operations require setup. See the billing guide.

Pending review: payment and renewal terms, tax responsibilities, cancellations, refunds, credits, fee changes, and the allocation of obligations when a builder charges its own users. No automatic invoicing, payout timing, or tax-handling commitment is made here.

Service operation and data lifecycle

Inlay is in private beta and the platform is evolving. Confirm operational requirements before depending on it for a workload. This page provides no service-level, uninterrupted execution, backup, recovery, or data-retention guarantee.

Pending review: availability and support terms, export and offboarding processes, retention and deletion across data categories, and the treatment of records after access ends. The draft privacy policy identifies the data categories that need to be covered.

Legal provisions awaiting approval

The contracting entity and contact address, governing law and jurisdiction, dispute process, warranties, liability allocation, indemnities, termination terms, and change-notice and acceptance procedures remain unresolved. No liability cap or waiver is supplied as a placeholder.

A final version requires legal and owner approval. Existing participants should raise agreement questions in their onboarding conversation. Prospective builders can use Request access to ask about the current onboarding process. This draft is not a substitute for an approved agreement.