Design Philosophy

Runnit is designed around one shared set of organisation and project data. The brief, resource plan, people, tasks, schedule, files, history, and agent outputs stay connected instead of being copied into separate tools.

Central data, used everywhere

Information is organised around a small set of connected records:

Record	What it connects
Organisation	Team members, roles, permissions, rates, capacity, settings, and clients
Client	Brand material, briefing rules, projects, assets, and client access
Master project	A campaign or programme containing related projects, budget, and dependencies
Project	Brief, team, tasks, dates, budget, files, and history
Task	Assignee, status, priority, schedule, estimate, time, comments, and completion details
Asset	Files, folders, versions, tags, search data, and links to clients, projects, or jobs
Agent job	Instructions, approved context, progress, output files, and the project or brief it belongs to

This means a task update can appear in the project timeline, dashboard, schedule, history, and chat context without someone entering it again. A file added to the right client or project collection can be found by people, search, and authorised agents.

People and agents use the same source

Runnit features and AI agents read the same approved records. An agent can use a brief, brand assets, project tasks, or schedule data when that information is in scope. Its outputs are saved back into the relevant job, project, or asset collection so the team can review and reuse them.

Agents do not bypass access rules. They work with the organisation, client, project, and file access of the connected user and job. If a person cannot read or change something, an agent acting for that person should not gain extra access.

The delivery chain

The main flow keeps each step connected:

Client context and brand assets
        ↓
Brief Builder draft and guidance
        ↓
Resource plan: roles, people, agents, tasks, dates, cost
        ↓
Activated project: team, schedule, brief, files
        ↓
Task updates, time, comments, history, outputs
        ↓
Dashboards, search, chat, reporting, and future work

The purpose is practical: less re-entry, clearer ownership, better context, and more reliable automation. The quality of every downstream feature still depends on keeping the shared data accurate.