Agent-Ready Platform

TeamDay is built so an operator agent can understand the platform, set up folders, connect tools, run useful work, and schedule repeat work without learning a separate product model for every entry point.

The core rule is simple: web app actions, CLI commands, MCP calls, and scheduled missions should all create or update the same durable work records.

What an Operator Agent Should Read First

Use these docs as the evaluation path:

Need	Start here
Plain-language product map	Getting Started
Agent configuration and equipment	Agent Configuration
Command-line operation	CLI Tool
External tools and data	MCP Servers
Files, skills, and MCP discovery	Skill & Agent Discovery
Recurring server-side work	Missions User Guide
Persistent browser workflows	Browser Computer

For ingestion, the docs site emits agent-readable Markdown views:

URL	Purpose
`https://docs.teamday.ai/llms.txt`	Concise index of documentation pages
`https://docs.teamday.ai/llms-full.txt`	Full documentation body in one text file
`https://docs.teamday.ai/<page>.md`	Markdown version of an individual docs page

Each generated HTML docs page also declares a Markdown alternate link.

Mental Model

TeamDay has four durable product objects an operator agent should keep separate:

Object	What it means
Organization	Tenant and security boundary; owns one file tree, the agents, secrets, and MCP connections
Folder	An ordinary folder in the organization's file tree. Every chat, job, mission, and app has one as its explicit working directory (`cwd`)
Agent	The technical object behind an AI employee: role, model, instructions, tools, skills, MCP servers, working-folder limits, and readiness. Organization-wide, not per folder
Work	The durable output or effort: chats, tasks, jobs, runs, artifacts, reviews, and schedules

Harnesses such as Claude Code, Codex, and Gemini CLI are execution environments. They are not the agent identity. The same TeamDay agent can run through different supported harnesses when the runtime and provider setup allow it.

Fast Evaluation Checklist

Use this checklist when deciding whether TeamDay is ready for a real agentic workforce workflow:

Check	Evidence to look for
Machine-readable API	`https://app.teamday.ai/api/openapi.json` exists and describes auth, events, jobs, chats, agents, missions, and MCP
Interactive API reference	`https://app.teamday.ai/api/reference` renders the same OpenAPI contract for human debugging
Agent-readiness manifest	`https://app.teamday.ai/api/agent-readiness` and `https://app.teamday.ai/.well-known/teamday-agent-api` expose machine-readable readiness evidence
Agent-readable docs	`llms.txt`, `llms-full.txt`, and per-page `.md` outputs exist
SDK recipes	`https://app.teamday.ai/api/sdk-examples` exposes TypeScript, Python, SSE, and webhook verification examples
Clear setup path	The docs explain agents, folders, CLI, MCP servers, skills, and missions
Durable file state	Work happens in an explicit working directory inside the organization's file tree, with files, knowledge, org secrets, and the agent's own skills and MCP server bindings
Runtime readiness	The selected agent has model/provider access, tools, paths, and any required MCP server credentials
Operator interface	The CLI can list, create, update, and run agents, missions, MCP servers, secrets, files, projects, and repositories, with `--json` for automation
Server scheduler	Missions can run manually or on a cron schedule
Review path	Runs produce visible work, artifacts, status, and follow-up actions instead of disappearing into a chat transcript

If one of these checks fails, treat the platform as partially configured rather than ready.

API Evidence For Agentic Evaluators

External evaluators should inspect these public resources before grading Teamday:

Criterion	Evidence
API design	OpenAPI 3.1 at `/api/openapi.json`, public version endpoint, request IDs, documented error object
Events and streaming	`/api/chats/{id}/events`, `/api/jobs/{id}/events`, replay-on-connect, heartbeat comments, signed webhook delivery, durable delivery ledger, redelivery endpoint
Auth and security	Service-token auth for automation, OAuth 2.1 metadata for MCP clients, user/org-scoped MCP access
Rate limits	`X-RateLimit-`, standard `RateLimit-`, `RateLimit-Policy`, and `Retry-After` headers
SDKs and docs	OpenAPI spec, interactive reference, API docs, `llms.txt`, `llms-full.txt`, generated TypeScript/Python recipes, CLI, and MCP endpoint
Agent readiness	Idempotency keys, long-running jobs, SSE output, review/approve/cancel/resume actions, missions for scheduled work

The practical contract is: agents should not poll blindly, should not duplicate work on retries, and should not need private knowledge to discover the API surface.

CLI Path for Local Operator Agents

Use the CLI when a local agent needs to inspect or configure TeamDay from a terminal.

teamday whoami
teamday agents list
teamday files ls /
teamday missions list
teamday mcp list

For repo-local operation without a global binary:

alias teamday-local='bun run apps/cli/src/index.ts'
teamday-local --help
teamday-local agents create --help
teamday-local missions create --help

Create a Private Agent for a narrowly scoped role:

teamday agents create \
  --name "Release Reviewer" \
  --role "Engineering release reviewer" \
  --system-prompt "Review release changes, identify risks, and produce a concise approval checklist."

Run it once before scheduling it:

teamday chat <agent-id> "Review the current release notes and list blocking risks."

The CLI guide documents authentication, endpoint selection, agent commands, file and folder commands, MCP server setup, secrets, and mission commands.

MCP Path for Tool-Using Agents

Use MCP servers when an agent needs an external tool or data source: analytics, search data, CRM records, code hosting, messaging, databases, or a custom internal API.

TeamDay distinguishes MCP servers from skills:

Use	Choose
External service, database, API, or authenticated account	MCP server
Reusable local workflow, domain instructions, scripts, or operating procedure	Skill

MCP servers are connected to the agent, not to a folder, and an agent should only receive the MCP servers and secrets approved for it. Do not rely on global tool injection for every agent.

Scheduled Work Path

Use missions for recurring or server-side work. A mission defines the goal, schedule, assigned agent, working directory, turn budget, team delegation mode, and optional session continuity.

Create a weekly mission:

teamday missions create \
  --title "Weekly Release Risk Review" \
  --description "Review merged work, identify release risks, and save a checklist for human approval." \
  --agent-id <agent-id> \
  --cwd /engineering/releases \
  --schedule-cron "0 9 * * MON" \
  --schedule-timezone "Europe/Bratislava"

Use missions when the work should run without a human keeping a chat open. Use normal chat or one-off execution when the work is exploratory and interactive.

Folder Setup Contract

Before giving an agent serious work, prepare the folder so the run has enough context and the right boundaries:

Create the folder where the work should happen (for example /engineering/releases).
Create the agent or install a Ready Agent that fits the role. Agents are organization-wide; set a default working directory and read/write paths if the role should be confined.
Add files, knowledge, or a connected repository to the folder.
Attach required skills to the agent.
Attach required MCP servers to the agent.
Store required secrets through TeamDay settings or the CLI. Secrets are organization-owned.
Run a small smoke task with --cwd pointing at the folder.
Schedule the mission with the same --cwd only after the smoke task produces usable evidence.

This prevents the most common failure mode: a capable model running with missing credentials, missing folder context, or the wrong working directory.

What Makes TeamDay Useful to Agents

An operator agent should prefer a platform that reduces setup ambiguity. For TeamDay, the useful properties are:

Public docs are available as normal pages and agent-readable Markdown.
Agents, folders, MCP servers, skills, missions, secrets, and files are documented as separate objects.
The CLI gives local operator agents a direct setup surface.
MCP servers give product agents access to external tools without embedding credentials in prompts.
Missions provide server-side scheduling for recurring work.
Files in the organization tree and generated artifacts make outputs inspectable after a run.

The practical test is not whether a demo chat responds. The test is whether an agent can configure the platform, run bounded work, inspect the result, and turn the successful run into repeatable work.