Introducing Melete

Start on your own, then bring in the team

Most work starts with one person. In Melete, your questions, research, and drafts begin in your own space, so you can think through a problem or prepare for a meeting without broadcasting every step. When the work is ready for others, you share it.

Bringing people in means creating or joining a project. The project holds the goal, the source documents, the drafts, and the decisions for that piece of work. For a customer pilot, that could be the discovery notes, the success criteria, and the onboarding owner. A teammate can check those sources without seeing anything else you have been working on.

Keeping this together makes a result easier to review. If a date looks wrong, you can see where it came from. If the scope changes, the team updates the plan in the place everyone already works.

It also gives the next person somewhere to start. A new teammate can read the current brief, follow its sources, and see who owns each task before asking for a meeting to catch up.

Where agents do the work

Take a request to compare three support tools before a purchasing meeting. The agent needs to read the team’s requirements, check current pricing and integrations on each vendor’s site, and explain the tradeoffs with links to the original pages.

Melete runs that work in an isolated environment with a browser, files, and code tools. The agent researches, reads documents, runs a small script when a comparison needs one, and prepares the result there. The environment is separate from your devices, and model provider keys stay outside it.

Choose what an agent can reach

A task can use only the sources and tools connected to it: selected Slack channels, specific Notion pages, particular repositories. You decide who can see the work and which actions need review. Before an external message goes out, its owner can check the content and the recipients.

Actions are tracked as they happen. If a task is interrupted, it resumes without repeating steps that already finished. If Melete cannot confirm that an action went through, it marks the action unconfirmed and asks someone to check, instead of trying again and risking a duplicate.

Keep work moving in the background

Agents can run several tasks at once and keep going while you are away. Schedule a Monday summary, watch an open escalation for changes, or collect the weekly updates from each team. Longer projects keep their context from one session to the next.

Notifications should have a reason: a useful result, a meaningful change, or a decision that needs you. A vendor changing its pricing or a launch date moving deserves attention. An unchanged check does not.

Documents people can check

Melete turns finished work into documents: a launch brief, a research memo, a customer handoff, a weekly update. Each one is useful to people who were never part of the conversation that produced it.

A brief carries its sources and the decisions still open. Teammates can review it together, assign the next steps, and export a copy. The person receiving it has enough to check the recommendation and understand how it was reached.

A customer handoff, for example, can include the discovery notes, the agreed success criteria, and the onboarding owner. Sales and customer success review the same document before the pilot begins, so nobody works from a different version of what was promised.

Memory with a scope

Product terminology, past decisions, a customer’s constraints, and your own writing preferences should all be available when the next task starts. The right memory saves people from repeating themselves.

Melete keeps that knowledge as memory you can inspect. Each entry links back to the source it came from. Read an entry, correct it when something changes, or delete it when it no longer applies. A correction takes effect immediately.

Scope decides who a memory informs. Company knowledge is available across the workspace, project context stays with its team, and private notes stay with you. Saving a note does not make it a company-wide reference. Sharing is a deliberate step.

Approvals before consequential actions

An agent can draft a customer email, but the account owner may need to check the recipients, timing, and wording before it goes out. That review is a step in the workflow, not a setting buried in an admin panel.

Melete shows the proposed action and assigns it to a reviewer. The reviewer sees exactly what will happen, then approves it or asks for changes. The decision is recorded with the work, so the team can see who reviewed what and what happened next.

Access settings decide which sources and tools an agent can use. The activity record shows what it read, what it proposed, and each decision along the way. Together they let a team trace an unexpected result and adjust how the workflow runs.

Models and the open core

Teams use different models for different work. They may choose a hosted provider for one workflow and a local model for another. Those choices should not mean moving a project or rebuilding company memory.

Melete works with OpenAI, Anthropic, and Google models, and with local models served through an OpenAI-compatible API. Projects, memory, and documents stay in the workspace when you switch.

The core agent harness, the part of Melete that runs agent tasks, enforces approvals, and keeps memory, is open source. Teams can read how agents run and host the harness on their own infrastructure. Browse the code on GitHub

Whichever model does the work, your company keeps its knowledge, projects, and decisions in one workspace.