Architecture

How Raintree works.

A short 5-minute explanation on how our system is wired up internally.

What is it?

Raintree is a company AI agent your team talks to through the communication channels it already uses. It pairs off-the-shelf AI models with the context, tools, and permissions your company approves.

The setup is opinionated on purpose: we handle the choices and edge cases teams often do not know to look for when building this capability for the first time. As your team gets better at AI, it can add its own tools, models, and rules on top.

The workflow, approval boundaries, and saved context stay with your company, so you can reduce our support or run it in-house without starting over.

01Request to result

One request, end to end.

See how a team message becomes a checked result—from the company setup and approved systems to any required approval and the answer returned.

A team message follows its assigned company setup, uses only approved business systems, pauses for approval when required, and returns the checked result to the team.

A team message follows the company instructions, approved systems, and approval rules assigned to that role. Raintree plans the next step, uses approved company information or services, checks what comes back, and repeats when needed. A person approves controlled actions before anything changes, and the result returns to the team.

In plain language

Each role has an assigned company setup that defines the instructions, business systems, and approval rules Raintree must follow. The team does not need to choose these parts each time it asks for work.

Raintree checks what it needs, uses only approved systems, and reviews what comes back before it answers. If a step can change a company system, the flow pauses so a person can approve it before anything changes.

Under the hood, each role runs as a governed agent loop: the role's instructions and allowed systems load at the start, every use of a system is a structured, logged call, and any step that could change a company system pauses for explicit approval before it runs.

02Access boundary

Everyday use stays separate from admin control.

Team members ask Raintree for work in the channels they already use. Only company admins enter the main controls to set the company rules and approval boundaries.

Team members use Raintree in approved channels while the main controls and company rules remain available only to company admins.

Team members ask Raintree for work through approved channels and receive the result there. They do not enter the admin controls. Only company admins choose the roles, instructions, connected systems, and approvals that shape how Raintree works.

In plain language

Team members ask for work and receive the result in an approved channel. They do not need access to the main controls.

Company admins choose the roles, instructions, connected systems, and approvals that shape how Raintree works. Those controls stay behind the admin boundary.

Under the hood, the workspace gateway creates isolated admin, company, and cron profiles. A resolved control-plane membership role gates dashboard routes and profile tool mounts; tools.approvalMode stays on always-ask for writes, while skill toggles and memory or skill write tools remain admin-only.

03Reviewed improvement

See what works, then improve it.

A clear record and repeatable checks show managers what is working, what needs attention, and whether a proposed improvement actually helps.

Real work creates a clear record. Managers define examples of good work, make one focused change, try it on fresh examples, and approve it before use.

Everyday work leaves a clear record of the task, information used, action, approval, and outcome. Managers define examples of good work, make one focused change, try it on fresh examples, and approve it before the team uses it.

In plain language

A clear work record saves the question, information used, action, approval, and outcome. Managers can turn expectations into examples of good work that Raintree can check against.

The proposed change is tried on fresh examples that were not used to create it. A manager reviews the results and decides whether the change is ready to use.

Under the hood, traces preserve model turns, tool calls, tool results, approvals, and outcomes. Eval cases exercise the changed contract; holdout cases stay outside the tuning set; only an admin-approved release moves updated profiles, skills, or tool policy into use.

04Memory over time

The agent remembers what matters.

Raintree saves useful facts, decisions, preferences, and background from completed work, then brings back what matters for a later task. When a way of working proves useful more than once, it can become a repeatable company process that improves over time.

Completed work adds useful company memory. Later work brings back what matters. Methods that prove useful can become repeatable company processes that improve over time.

Completed work can add useful facts, decisions, preferences, and background to company memory. Raintree brings back what matters when later work begins. A method that proves useful can become a repeatable company process that improves over time.

In plain language

Useful company memory keeps facts, decisions, preferences, and useful background after work is complete. When new work begins, Raintree brings back the parts that can help, so it does not start from zero.

A repeatable company process documents a method that proved useful. It can be created or updated as the team works, so Raintree follows better company-specific steps over time. The underlying AI model is not retrained.

Under the hood, Raintree keeps its saved context in a private memory store on company infrastructure. Completed work is indexed so later tasks can search it, and methods that prove useful are captured as repeatable company procedures. All of this changes the context and instructions Raintree works from, never the AI model itself.