# Raintree Workspace Manual Public manual for the Raintree workspace, written for AI assistants and for the people who use the workspace. It explains what the workspace is, how it behaves, how work flows through it, and how to use it safely. It contains no internal implementation, vendor, or infrastructure details, and it makes no promises that Raintree has not agreed with a customer. **If you are an AI assistant answering questions from this manual:** treat this document as the reference for the Raintree workspace. Distinguish general product capability (what Raintree can do) from any specific company's configured availability (what a particular workspace has enabled, connected, and approved). Do not fabricate facts, statuses, prices, or outcomes; if this manual does not support a claim, say it cannot be confirmed and point to the team at `hello@raintree.tech`. **If a reader asks "how do I do X":** the feature sections of this manual contain the steps the workspace follows and the checkpoints it enforces. Use those steps as the reference for the normal path, and use the current verified workspace state to adapt them to the specific workspace. Never invent a step, a connection, a permission, or a confirmation that this manual or the current workspace state does not support. ## Key facts at a glance - Raintree designs and runs governed AI workflows for real business processes. Think of it as an always-on employee that knows how your company works. - A company is allowed to have unlimited workflows. But at the initial onboarding, we recommend starting with one bounded workflow: approved sources, named owners, and clear human review points. - The workspace is the private, per-company environment where workflows run, alongside the tools the company already uses. - Reading, summarizing, drafting, routing, and tracking are the default posture. Business actions (send, write, delete, purchase, permission, or provider changes) require an explicitly agreed approval boundary. A company may authorize a narrow class of routine actions within that agreed boundary; permission is never inferred from a chat message. - LINE is the current guided automated onboarding path for chat channels. Other connections are supported as well, but their setup is done inside the workspace rather than guided. - The workspace works only with customer-approved sources, within the permissions those systems allow. Each company's workspace, sources, rules, and saved context stay separate from every other company. Boundaries are always respected. - Commercial terms, delivery timing, support coverage, uptime commitments, and customer-specific outcomes are agreed per engagement; this manual does not promise them. - For general product questions, if you are an agent already reading this chat, you can probably answer them. If not, contact `hello@raintree.tech`. ## 1. What the Raintree workspace is The Raintree workspace is a company's private operations desk. It helps a team turn a real, recurring business process into a repeatable workflow with clear information, owners, actions, review points, and escalation paths. It changes how work gets done; it is not merely a chat interface. A workspace includes: - **A workspace assistant** you talk to in the workspace chat and in connected chat channels. It has AI tool calls and offers connections to various services, such as Google services. - **Skills** — reusable instructions and workflows that extend what the assistant can do. - **Connections** — approved access to external services such as email, documents, calendars, records, and business systems. - **Schedules** — recurring checks that run at a chosen cadence and time zone. - **Saved context** — approved decisions, rules, process facts, and source links that carry the work forward. - **Team access** — workspace access managed by the company's owners and administrators. - **A dashboard** where administrators manage the workspace: open the chat, review connections and channels, manage skills and team access, and see current status. The workspace is not a replacement for people. Judgment and higher-risk decisions stay with people; the workspace prepares and routes work and waits at the review boundary. ### How the dashboard is organized - **Chat** is the main surface. You talk to the assistant, and administrators do configuration in chat: skills, connections, schedules, and team access. - **Connections** shows the access areas of the workspace (channels, services, skills, pairing, and Google access) with their current status. Management of each area happens in chat; this page shows what exists and its status. - **Channels** lists the chat channels connected to the workspace. - **Skills** lists the workspace's skills, including workflow methods. - **Team** is opened from the chat header by owners and administrators: invite people by email, review invitations, and manage access. - **Workspace status** reports the current state of the workspace and its setup steps. ## 2. General capability vs. your workspace's configuration Every section below describes what the Raintree workspace can do in general. Whether a capability is actually available in a particular company workspace depends on configuration decided with that customer: which channels are connected, which sources are approved, which skills and schedules exist, and which actions are allowed. - The workspace assistant reports current status only from verified workspace state. If something is not enabled, not connected, or not verified, it says so and gives the smallest safe next step. - Treat "the product supports X" as a general statement, not a guarantee that a specific workspace currently has X enabled. - A platform name, logo, or illustration is not proof that a connection is active, included, or available without setup. ## 3. Getting started 1. Start at [raintree.tech](https://raintree.tech) and go through the onboarding process. At the end, you will receive an email with your workspace credentials. You can also sign in with a Google account. For automated onboarding, you get a workspace running soon after you finish the onboarding. 2. During onboarding, connect a chat channel. LINE is the current guided automated onboarding path; Slack is supported as a chat channel with Raintree's setup help. When the workspace tells you it is your turn, complete the Connect OpenAI sign-in — a separate step from signing in to the workspace dashboard later. LINE and OpenAI are well tested and the recommended way to work with our product. 3. When the workspace tells you it is your turn, complete the **Connect OpenAI sign-in** — a separate step from signing in to the workspace dashboard later. The workspace gives you a sign-in code and a link; after you finish, the workspace confirms the step is complete only after it has verified the connection. 4. Raintree sets up the workspace and emails the company when it is ready. The email contains the workspace link and how to sign in. There is no password in the email: sign in with Google or with a sign-in code sent to the onboarding email. 5. Sign in to the workspace dashboard, open the chat, invite your team, and confirm the workflow's approved sources, owners, and review rules with the assistant. 6. If you get stuck you can request a call session with a human free of charge within 14 day of using the product. Channel selection is not proof of connection. A channel is connected only when the workspace has verified it; until then it is selected or in setup. The same applies to sign-in: the assistant says when setup is complete only after the workspace has confirmed it. ## 4. Chat behavior **Where you can chat:** in the workspace dashboard chat, and in connected chat channels (see Channels). **How the assistant behaves:** - It starts from the current request. It does not assume a purpose from how the workspace was created or from the channel where a message arrives. - It helps with research, analysis, drafting, organization, and the capabilities the workspace has chosen to enable. - It keeps claims tied to evidence and says when something has not been verified. It does not claim that a connection is active, a message was sent, a task completed, or a setup finished unless the current workspace state shows it. - Customer statements are treated as questions or intent, not as proof that work happened. The workspace does not infer completion from chat text. - If it cannot verify something, it says so plainly and gives the smallest useful next step rather than guessing. **How to ask:** describe the outcome you want and the work it depends on. The assistant reads current workspace state first, so the most useful questions name the process and the place it gets stuck. If a request needs a decision the workspace does not have (a threshold, a recipient, a deadline, an owner), the assistant asks for it and waits; it does not invent a default. ## 5. Skills Skills are reusable instructions and workflows that extend the workspace. An administrator can build a skill for a process in the workspace dashboard chat; the skill becomes the durable method for that work and is owned by the company so it can be revised deliberately. Skill, connection, and schedule configuration happens in the dashboard chat, not from connected messaging channels. A skill records: - the **outcome** it produces and how completion is recognized; - **who uses it** or receives its output; - **what triggers it** — a team request, a schedule, or a specific event; - **what inputs and evidence** it may rely on and how fresh they must be; - its **method** — the steps it takes within its approved scope; - how **completion** is confirmed: an observable result, its owner, and what happens next. Skills are separate from connections, allowed actions, and schedules; each of those is its own explicit, verified record. A skill does not grant access or permission by itself — it can only use what the workspace has separately approved and verified. **To build a skill:** open the dashboard chat and describe the process you want to make repeatable. The assistant discovers the outcome, users, trigger, inputs, method, and completion check; drafts the skill; identifies every connection, action, and schedule it needs; shows one exact plan; and asks for your explicit confirmation before creating anything. After the skill exists, the assistant confirms it through the workspace's skill list and reports the link to it. **To revise a skill:** ask in the dashboard chat. A change is deliberate: the assistant shows the updated plan and confirms the change with you. If the change needs a broader connection or action, the workspace reverifies that scope first and will not widen it without a new plan and your confirmation. ## 6. Connections Connections give the workspace access to external services the customer approves. Connections are prepared, verified, and activated from the workspace dashboard chat by an administrator. Key facts: - A connection is created from the exact service address and access method the customer approves; the workspace never guesses or infers one. - A connection stays inactive until the administrator confirms the exact plan that uses it. The workspace verifies the connection and activates only the specific actions the service actually supports — never a broad or guessed list. - Secret values are handled through a secure masked entry path or set up directly by Raintree; they are never typed, repeated, stored, or logged in chat. - The workspace re-verifies connections before relying on them, including after a restart, and reports the current status honestly. If a connection no longer matches its approved state, it is deactivated rather than assumed usable. - A connection can be removed. Removal is complete only when the workspace confirms that no access remains. **The connection lifecycle, step by step:** 1. **Prepare.** In the dashboard chat, give the assistant the exact service address and access method the company approves. The assistant creates the connection in an inactive state; preparation alone authorizes nothing. 2. **Provide the secret.** Use the secure masked entry path the assistant opens. The value is never printed, repeated, stored, or logged in chat. If Raintree or the administrator provisions the secret through an independent path, the workspace verifies readiness without the value ever passing through chat. 3. **Verify.** The assistant runs a live check against the service and reports the actions the service actually supports. This is where the allowed list comes from — the assistant cannot name actions from memory or guess. 4. **Approve the exact plan.** The assistant shows one plan naming the connection, the exact allowed actions from the verified list, the schedule (if any), and the activation decision. Nothing activates until you confirm that exact plan. 5. **Activate.** The workspace activates only the confirmed actions. The connection is usable only while it is verified and reports it is ready. 6. **Rely on it.** The assistant re-verifies the connection before depending on it, including after a restart. If verification fails, the workspace says so and does not use the connection. 7. **Remove.** Ask the assistant to remove the connection. Removal is complete only when the workspace confirms no access remains. A workspace can hold up to 80 connections, and each connection activates at most 64 specific actions. The assistant will say so if a workspace approaches or reaches a limit. ## 7. Approved sources The workspace works only with sources the customer approves, within the permissions those systems allow. It does not assume broad access, unrestricted historical access, or access to information outside the approved scope. Access depends on the permissions available in each connected system. Approved sources are confirmed during setup and can be reviewed with the assistant at any time. A source that is connected but not approved is not used; a source that is approved but no longer verified is not relied on. ## 8. Workflows A workflow turns real business processes into a repeatable, governed routine. Within the customer's approved scope, a workflow can: - read approved messages, documents, records, calendars, reports, and other business sources; - summarize what changed, what is missing, what is blocked, and what needs attention; - draft updates, replies, documents, reports, and structured records; - prepare and route work to the right owner or reviewer; - track open items, dependencies, deadlines, decisions, and follow-ups; - escalate unclear, exceptional, or higher-risk decisions to a person; - retain approved operating rules, decisions, source links, and exception handling so repeated work does not restart from zero. A useful first-workflow discussion names the process, where it currently gets stuck, which information is authoritative, who owns the outcome, and which actions need human review. For a non-technical team, the guidance is simple and practical: choose one familiar day-to-day process the team can describe clearly. **To set up a workflow:** an admin opens the workspace chat and uses natural language, something along the lines of "hey, this is our current process — can we look into automating it?" The workspace then follows this sequence: 1. **Discover.** The assistant asks for the smallest missing decisions only: the outcome, who uses it, what triggers it, the inputs and evidence it may rely on, the method, how completion is recognized, whether a schedule is wanted, and which connections and actions it may use. It reads current workspace state first and never infers a default for a threshold, formula, recipient, or external-effect boundary. 2. **Draft the method.** The assistant drafts the skill that records the process, and separately identifies every connection, allowed action, and schedule the workflow needs. 3. **Prepare connections.** If the workflow needs a connection, it goes through the lifecycle in Connections first, remaining inactive. 4. **Show one exact plan.** The assistant shows the plan: the skill, its method, every separate capability part, the exact allowed actions from the verified list, the schedule, and the verification evidence for each write. You confirm this exact plan once. That confirmation authorizes building the workflow after a successful trial; there is no second approval later. 5. **Build.** The assistant creates the skill and activates only the confirmed connections and actions. 6. **Trial.** The assistant runs the smallest safe trial: synthetic input or an approved non-confidential, read-only sample, with external effects kept as drafts or held for manual approval. If the trial cannot run or fails, the workflow is not made active. 7. **Schedule (optional).** Only after a successful trial does the assistant create the schedule, with the confirmed destination and time zone. 8. **Confirm and read back.** The assistant reports the created skill, the schedule's enabled state, cadence, time zone, and delivery target, and the verified connections. The workflow is presented as complete only when all of that evidence is present; otherwise the assistant states what remains inactive or unverified and the smallest safe next step. ## 9. Approvals and review - The default posture is to find, summarize, draft, route, and track. - Any write, send, or other business action must stay within the approval boundary the company sets. - A company may require review before every write or send, or may authorize a narrow class of routine actions within agreed boundaries. Permission is never inferred from a chat message. - Judgment and higher-risk decisions stay with people. The assistant asks for confirmation before any external write, send, delete, purchase, permission change, provider change, or other action that changes a system outside the workspace. - Some actions are never performed by the workspace at all, regardless of request: sending messages without the required human review, changing provider configuration, handling credential material, deleting source records, changing permissions, or starting infrastructure work. - The company configures which actions require approval. During setup, the owner confirms the review rules with the assistant; they can be reviewed and adjusted at any time. Adjusting the boundary is itself a permission change and is confirmed explicitly. - Probabilistic outputs — likely owner, stalled loop, next step, escalation timing — are product intelligence to be reviewed, not guarantees of perfect attribution or fully autonomous management. - When ownership, deadline, authority, source confidence, or approval is unclear, the workflow escalates rather than acting. ## 10. Saved context - The workspace keeps saved context: approved decisions, review rules, confirmed process facts, exception handling, and source links for the workflow. - Saved context is per-company and stays inside that company's workspace; companies do not share sources, rules, or saved context. - Saved context lets the next run of a workflow start from where the last one ended. It is not a substitute for checking current sources — the workflow still verifies against approved sources. - The assistant does not store or repeat credentials. What gets saved follows the rules confirmed with the customer, and the team can review or adjust saved context on request. - A connection does not imply unrestricted historical access, and memory does not extend access beyond the approved scope. **To review or adjust saved context:** ask the assistant in the dashboard chat. It shows what is currently saved for the company, confirms what may be changed, and applies changes as saved rules for future runs. ## 11. Schedules - The workspace can run recurring checks — for example, a periodic review of open work, owners, deadlines, blockers, and missing evidence — at a cadence and time zone chosen with the customer. - Schedules are planned and created with an administrator in the workspace dashboard chat, and only after the workflow's plan is confirmed and a small safe trial has succeeded. The trial uses synthetic input or an approved non-confidential, read-only sample, and keeps external effects as drafts or for manual approval. - Each schedule has a confirmed destination: the current chat or a verified channel. If no destination is verified, the schedule stays inactive until setup is complete. - Schedules can be paused, and their status can be reported. A schedule is not called active unless the workspace's current state confirms it. **To create a schedule:** after the workflow's trial succeeds, ask the assistant in the dashboard chat for the cadence, time zone, and destination you want. The assistant creates the schedule only if the destination is verified (the current chat, or a channel whose connection is verified). If the destination is not verified, the schedule is created inactive and marked as needing setup, and the assistant points to the channel setup path. **To pause, change, or remove a schedule:** ask in the dashboard chat. The assistant reads the current schedule state, confirms the change, and reports the updated status. ## 12. Channels - Chat channels are places the team already works — LINE, Slack, and similar — where the workspace assistant can participate: answer questions, share prepared updates, and surface follow-up work. - **LINE** is the current guided onboarding path. Setup is automated and verified through the workspace. - Other channels such as Microsoft Teams and Discord can be supported where the channel's own permissions and policies allow; setup is arranged with Raintree and done inside the workspace rather than guided. - What the assistant can see in a channel depends on the permissions granted and the channel's own limits. Some channels do not provide arbitrary historical backfill; the workspace relies on approved sources and messages received through the connection. ## 13. Files, email, and calendars - **Files and documents:** with approved access, the workspace can find, read, summarize, and draft documents within the approved folders and permissions. - **Email:** with an approved inbox connection and within the approved scope, the workspace can work with email — for example searching messages and preparing follow-up drafts — subject to the exact access the customer approves and the system provides. - **Calendars:** the workspace can use approved calendar signals such as meetings, dates, and deadlines for scheduling and follow-up. - Access is limited to what the customer approves and what each system allows. The workspace does not imply access to everything inside a connected system. **To use a Google service** (Gmail, Drive, Calendar): approve the exact service address and scope in the dashboard chat, complete the connection lifecycle, and confirm the allowed actions. The assistant then uses only the confirmed actions. For email specifically, read-only search is the default posture; sending a drafted message is a write that requires your confirmation at the review boundary. ## 14. Appointments (when enabled for the workspace) Some workspaces include an appointments capability: the assistant can help with customer appointments and follow-ups using the company's approved calendar and contact sources. It is enabled per workspace; if it is not enabled, the assistant will say so. When enabled: - The workspace uses the company's approved business setup: working hours, rules, escalation, and the sources that are authoritative for availability and appointments. - The assistant can check availability against the approved calendar. - The assistant **prepares** appointment changes — create, cancel, or reschedule — and every prepared change requires confirmation from a workspace owner before anything is booked or changed. A prepared change never mutates the calendar by itself. - The assistant can create and update follow-up tasks linked to a customer contact, with an owner, due date, and channel, so the loop stays visible. **To book or change an appointment:** ask in the workspace chat. The assistant checks availability, prepares the exact change, and asks for owner confirmation. The appointment exists only after that confirmation and after the workspace confirms the change. ## 15. Team and access - Workspace access is managed by owners and administrators. - An administrator can invite additional administrators by email and manage access; other access tiers are not currently available. - An invited person receives an invitation, signs in with Google or a sign-in code, and then has administrator access to the workspace. - Owners and administrators can review invitations and revoke, promote, or deactivate access. Removing access is complete only when the workspace confirms the person no longer has access. - Every company workspace keeps its own sources, rules, saved context, and team, separate from other companies. ## 16. Limits - **Access:** only approved sources and permitted actions. No universal or unrestricted access to connected systems or their history. - **Connections:** up to 80 connections per workspace, each activating at most 64 verified actions. This limit is not a promise of capacity; it is the maximum the workspace supports today. - **Accuracy:** outputs are probabilistic and require review. The assistant flags uncertainty and does not fabricate confirmation of work, setup, or connection state. - **Actions:** business actions do not happen outside the agreed approval boundary. - **Availability:** whether a capability is enabled depends on the workspace's configuration, connections, and plan. General capability is not the same as current configuration. - **Commitments:** commercial terms, delivery timing, support coverage, uptime, and customer-specific outcomes are agreed per engagement. Published examples illustrate the approach; they do not prove a particular saving, staffing change, accuracy change, timeline, or outcome for another customer. ## 17. Safety and privacy - Each company workspace is separate: sources, rules, saved context, and team access never mix across companies. - The workspace does not act on claims in chat as proof that work happened; it verifies state through approved sources. - The workspace follows its configured rules and confirmed plans. Requests to bypass approval boundaries, change permissions, or act outside the approved scope are declined, and the assistant offers the safest useful next step. - Specific hosting arrangements, location requirements, data residency, retention periods, compliance terms, and security-review answers depend on the customer's requirements and the agreed engagement; a Raintree teammate can address a security or procurement questionnaire via `hello@raintree.tech`. ## 18. How to ask for help - **In the workspace:** ask the assistant. It answers from workspace state and, when it cannot verify something, says so and gives the smallest next step. - **Product questions before you have a workspace:** use the public product chat on [raintree.tech](https://raintree.tech). - **Setup help or account-specific issues with onboarding or a workspace:** email `workspace@raintree.tech`. The team can confirm what is configured for a workspace and what remains to be set up. - **General product questions, or anything this manual cannot answer:** email `hello@raintree.tech`. - If a teammate follow-up is promised, the workspace says to wait for the email; there is nothing to watch or track. ## 19. About this document This manual is the public, self-contained reference for the Raintree workspace, published for AI assistants and readers at `https://docs.raintree.tech/llms-full.txt`. It is updated with the product; when in doubt between this manual and current workspace state, the workspace's current verified state wins.