Project Manager Tools - Genesis Computing

Overview

Tool Name

project_manager_tools

Purpose

The project_manager_tools suite organizes work into missions and todos. It supports creation, assignment, dependencies, bulk operations, work recording, asset management, and starting existing blueprints as tracked Missions so projects move from plan to done with clear ownership and traceability.

Key Features & Functions

Plan Missions

Create and update missions with descriptions, status, and timelines, or retire a mission that should not resume.

Track Todos

Create, assign, and update todos with rich details and statuses.

Manage Dependencies

Add or remove todo relationships to enforce execution order.

Record Progress

Log work done with outcomes for audit-ready history.

Handle Assets

Attach and manage mission assets like files, links, and git paths.

Scale With Bulk Ops

Create or delete many todos at once with optional dependency wiring.

See Data Agent Involvement

List data agents assigned to missions and todos for load visibility.

Use a short, action-oriented mission name and a precise todo title. It keeps lists scannable and status meetings fast.

Project-aware calls continue using a thread’s saved active mission when the chat thread is reopened or no longer has a live in-memory thread object. If Genesis has already confirmed that the thread has no active mission, it persists that empty state too so later calls do not re-resolve a project unnecessarily.

Input Parameters for Each Function

`manage_todos`

Parameters

Name	Definition	Format
action	Operation to perform. One of `CREATE`, `UPDATE`, `GET_TODO_DETAILS`, `CHANGE_STATUS`, `LIST`.	String
for_bot_id	Act on behalf of another data agent.	String
todo_details	Structured details payload for create or update.	Object
project_id	Mission id that owns the todo. Required for `CREATE`.	String
todo_name	Todo title. Required for `CREATE`.	String
what_to_do	Detailed description of the work. Required for `CREATE`.	String
depends_on	One or many todo ids that must complete first.	String or List
assigned_to_bot_id	Data Agent id to assign the todo to.	String
new_status	Target status for `CHANGE_STATUS`. One of `NEW`, `IN_PROGRESS`, `PAUSED`, `COMPLETED`, `CANCELLED`.	String
todo_id	Target todo id for `UPDATE` and `CHANGE_STATUS`.	String

`manage_projects`

Parameters

Name	Definition	Format
action	Operation to perform. One of `CREATE`, `UPDATE`, `CHANGE_STATUS`, `LIST`.	String
for_bot_id	Act on behalf of another data agent.	String
project_details	Structured details payload for create or update.	Object
project_name	Mission name. Required for `CREATE`.	String
description	Mission description. Required for `CREATE`.	String
new_status	New status for `CHANGE_STATUS`. One of `NOT_STARTED`, `IN_PROGRESS_ACTIVE`, `IN_PROGRESS_WITH_FAILURE`, `IN_PROGRESS_NEEDING_INPUT`, `PAUSED`, `STUCK`, `FAILED`, `COMPLETED`, `CANCELLED`, or `RETIRED`.	String
reason	Why the mission is being retired. Required when `new_status` is `RETIRED`.	String
project_id	Mission id for `CREATE` response mapping and for `UPDATE`.	String

Set new_status to RETIRED when work stopped early and the mission must remain terminal. Include a non-empty reason; retired missions cannot return to an active state or continue Blueprint execution.

Project and todo ids are generated by the platform. Store them in your automation so later updates and dependency wiring are reliable.

`start_blueprint_mission`

Start an existing blueprint as a tracked Mission from the current thread. This is the supported execution path when the user asks Genesis to run, execute, kick off, or create work from a blueprint. Genesis creates or reuses the Mission/project, links it to the conversation, and enters the requested phase automatically before the kickoff turn begins. Parameters

Name	Definition	Format
blueprint_name	Existing blueprint name to run. Required.	String
mission_name	Optional Mission/project name. When omitted, Genesis derives a name from the blueprint.	String
description	Optional Mission description or kickoff context. Benign formatting tags such as `<b>` are accepted; dangerous HTML remains rejected. When omitted, Genesis stores `Mission created from blueprint '<blueprint_name>'.`	String
phase	Entry phase to start. Defaults to `"0"`.	String
mode	Blueprint execution mode. When omitted, the blueprint’s `default_mode` applies, which is `goal` for most shipped blueprints and for new ones; a running Mission keeps its recorded mode. For a new Mission of a blueprint without a valid `default_mode`, an omitted mode returns `mode is required`, so pass one explicitly. `goal` advances phases automatically and pursues each phase’s exit criteria under goal-mode limits, `manual` lets the user drive phase transitions, and `continuous` is a legacy value still accepted for callers that name it.	String
goal_statement	Optional goal description in the person’s words. Used only in `goal` mode; when omitted or blank, the goal names the blueprint.	String
source_context	Optional blueprint source selection. Use `default` for the production/default source or `wip` for the caller’s active working copy.	String
llm_provider	Optional default LLM provider for the Mission thread.	String
llm_tier	Optional default LLM tier for the Mission thread. One of `frontier`, `main`, or `fast`.	String
demo_scope	Required canonical presenter scope when the blueprint carries the `demo:disposable` tag. Use 1–32 lowercase letters and digits with single hyphens between words; spaces, uppercase, and underscores are rejected. In the web UI, start disposable demos from Presenter Controls so Genesis derives and locks the scope — do not type a scope manually in the Start Mission modal.	String
preserve_active_phase_on_reuse	Optional. When `true`, reusing an existing Mission preserves its verified active phase; if no verified phase exists, Genesis enters the requested `phase`. Defaults to `false`.	Boolean (default `false`)

bot_id, thread_id, and user_id are supplied implicitly by Genesis at runtime. start_blueprint_mission requires a current thread so the Mission can be linked to the active conversation.

If _blueprint_tool(action="GET_BLUEPRINT_INFO", ...) reports requires_source_selection=true, choose source_context explicitly before calling start_blueprint_mission. Use _blueprint_tool for blueprint discovery, registry management, or lower-level recovery, not for manually executing steps copied from blueprint metadata.

Example

start_blueprint_mission(
    blueprint_name="data_vault_build",
    mission_name="Data Vault Buildout",
    description="Build the first customer-ready warehouse skeleton.",
    phase="0",
    mode="manual",
    source_context="default",
    llm_tier="main",
)

To state the outcome explicitly in goal mode, pass goal_statement:

start_blueprint_mission(
    blueprint_name="data_vault_build",
    mode="goal",
    goal_statement="Deliver a validated first customer-ready warehouse skeleton",
)

In goal mode, the kickoff tells the agent to advance sequential phases with PROCEED_TO_NEXT_PHASE without asking for confirmation, stopping for a blueprint-directed gate or when operator input is needed. See Goal mode transitions for phase criteria and transition behavior. Successful responses include project_id, repo_id, phase, requested_mode, reused_existing_project, and both project_result and phase_result for follow-up inspection. When phase entry succeeds, mode reports the mode actually applied; it can differ from requested_mode if goal mode could not be applied. If an existing phase is preserved with preserve_active_phase_on_reuse=true, mode reports that phase’s current mode. A response where phase entry did not start omits mode, because no new mode was applied. When a phase is preserved, the response also includes active_phase_preserved: true, the canonical active_phase, and the originally requested requested_phase; phase reports the preserved phase number. When a phase starts without preserving an existing active phase, Genesis also writes a MISSION_STARTED INFO log anchor. The system-test blueprints use it for error attribution; see Blueprint system-test guidance. Policy-blocked mission start When workspace High-Risk Tool Controls block tools the blueprint requires, Genesis returns success: false before creating a mission. The response includes a human-readable error plus structured fields:

Field	Type	Description
`code`	string	`blueprint_tool_policy_blocked`
`policy_blocked`	boolean	Always `true` for this failure.
`blocked_policy`	string	`high_risk_tools_disabled` when the workspace toggle blocks the high-risk tool family.
`blocked_tools`	object[]	Each item includes `name`, `display_name`, and `description` for a blocked tool such as `execute_python_code`.
`blueprint_name`	string	Blueprint that was requested.
`bot_id`	string or null	Agent id used for the preflight check.
`source_context`	string or null	Source selection passed to the tool, when set.
`admin_location`	string	UI hint for where an admin enables high-risk tools (`Config > Users > High-Risk Tools`).
`admin_path`	string	Config path hint (`/config/users`).
`manual_execution_guardrail`	string	Instructs the agent not to run blueprint phases manually while required tools stay blocked.

Enable the high-risk tool family under Workspace Policies, then retry start_blueprint_mission. If Genesis cannot load the blueprint manifest for preflight (for example an unresolved source_context="wip" source), the tool also returns success: false with manual_execution_guardrail and does not create a mission. MCP / agent-to-agent continuous kickoff For an external agent that should drive the blueprint between configured gates, use mode="continuous". Continuous mode does not bypass a phase whose manifest sets require_human_approval: true: Genesis pauses the mission and sends the approval request to the originating Google Chat conversation when that transport is available. continuous is a legacy mode kept for existing integrations; a new integration can omit mode to run in the blueprint’s default, normally goal. Standard chat and UI starts use that default too, and pass mode="manual" when the operator will drive phase transitions. From the Genesis MCP v2 genesis tool you can start the Mission in the same pattern as other initial tool calls, for example:

genesis(
    action="thread_create",
    agent_id="Adam",
    initial_action="tool_call",
    initial_tool_name="start_blueprint_mission",
    initial_arguments_json='{"blueprint_name":"data_vault_build","mode":"continuous"}',
    submit_mode="async",
)

Partner or host applications that supervise missions from their own UI should use the REST BlueprintRun API (POST /api/blueprints/{name}/runs, POST /api/runs/{run_id}/input/{input_id}) rather than start_blueprint_mission. See Programmatic BlueprintRun.

`record_todo_work`

Parameters

Name	Definition	Format
todo_id	Todo id to record work against.	String
work_description	Narrative of what was done.	String
work_results	Outputs, findings, or links to artifacts.	String
for_bot_id	Act on behalf of another data agent.	String

`get_todo_history`

Parameters

Name	Definition	Format
todo_id	Todo id whose history to return.	String

`get_project_todos`

Parameters

Name	Definition	Format
project_id	Mission id to list todos for.	String
for_bot_id	Act on behalf of another data agent.	String

`get_todo_dependencies`

Parameters

Name	Definition	Format
todo_id	Todo id whose dependencies to retrieve.	String
for_bot_id	Act on behalf of another data agent.	String
include_reverse	Include todos that depend on this todo when `true`.	Boolean

`manage_todo_dependencies`

Parameters

Name	Definition	Format
action	One of `ADD` or `REMOVE`.	String
todo_id	The dependent todo id.	String
depends_on_todo_id	The prerequisite todo id that must complete first.	String
for_bot_id	Act on behalf of another data agent.	String

`delete_todos_bulk`

Parameters

Name	Definition	Format
todo_ids	Array of todo ids to delete.	List of String
for_bot_id	Act on behalf of another data agent.	String

`create_todos_bulk`

Parameters

Name	Definition	Format
project_id	Mission id for all created todos.	String
todos	Array of todo objects. Each supports `todo_name`, `what_to_do`, optional `depends_on`, `assigned_to_bot_id`, `todo_type`, `fields`.	List of Objects
for_bot_id	Act on behalf of another data agent.	String

`manage_project_assets`

Parameters

Name	Definition	Format
action	One of `CREATE`, `UPDATE`, `DELETE`, `LIST`, `GET_DETAILS`.	String
project_id	Mission id that owns the asset.	String
asset_id	Asset id for `UPDATE`, `DELETE`, `GET_DETAILS`.	String
asset_details	Structured details payload.	Object
description	Asset description for `CREATE` and `UPDATE`.	String
asset_type	Type such as `GIT`, `FILE`, `LINK`, `G-SHEET`.	String
git_path	Git path when asset type is `GIT`.	String
data	Arbitrary JSON metadata.	String

Checked project records

The record-writing and detail tools create and maintain typed project records with declared goals, versioned assets, attributed notes, and server-checked evidence. They are separate from the mission and todo tools above and belong to their own tool group, project_record_tools: a thread with only project_manager_tools active does not have those tools. A mission phase starts with them only when its blueprint lists project_record_tools for that phase; otherwise the agent can add the group itself with manage_context, if its tool policy allows the group and the provider’s function limit has room, and must add it again after the next phase starts. project_list is also available through context_tools, which new chats hold. This slice currently supports palantir_databricks, which is opened by planning the Foundry space with foundry_plan_migration and not by project_open, with three interim goals pending their final definitions: landed uses foundry_copy_receipt, rebuilt_and_ran uses databricks_run, and proved uses prover_grade. A landed check accepts only a Foundry copy the server filed under this project and goal.

`project_list`

Lists the signed-in person’s live checked migration projects, newest first, with each goal’s status and the next tool call for continuing the project. Call this first when someone asks about a migration they already started, including from a new chat; it does not list Missions, TODOs, retired projects, or another person’s projects. Use the returned project only when it matches the work they named. Answer status questions from the listed goals, and follow next only when they want to continue. If no listed project matches, search threads, runs, or proofs rather than saying the work does not exist. Use project_read for a project’s notes and evidence.

Name	Definition	Format
user_id	Signed-in person’s id, supplied implicitly from the conversation context.	String or null (optional, default `null`)

The response contains projects, truncated, and unreadable. Each project includes its id, name, project_type, source, created_at, plan_incomplete, goals (including status and planned done-of-total counts), and next. When multiple projects share a source, same_source_as explains how to choose which one to continue. Do not call a project complete while plan_incomplete is true. An empty projects list means the person has no checked migration project under way only when truncated is false and unreadable is empty. Report unreadable ids as projects that exist but could not be read. On success: false, report the error briefly. Cost: one database SELECT when the person has no live project; otherwise three SELECTs for their 20 newest live projects, their goals, and notes. It does not call a source system.

`project_open`

Name	Definition	Format
name	Name for this project instance.	String (required)
project_type	A declared type that is opened by hand. `palantir_databricks` is refused here: plan the Foundry space with `foundry_plan_migration`, which opens that project with its scope.	String (required)
parameters	Object containing `source`, `targets`, and `rendering`.	Object (required)

A Palantir-to-Databricks migration project is not opened with this tool. Planning the Foundry space with foundry_plan_migration opens it for the signed-in person, or resumes the one they have, and returns its id in the plan’s project block; calling project_open with palantir_databricks returns success: false and names that tool. No project type declared today is opened by hand. For a type that is opened by hand it returns the new project id and project_type; use that id with project_note and project_read. Unknown project types, missing parameters, or undeclared parameter names return success: false.

`project_note`

Name	Definition	Format
id	Project id. For a Foundry migration it is `project.id` in `foundry_plan_migration`’s answer; for a type opened by hand, the `id` `project_open` returned.	String (required)
goal	Goal declared by the project type.	String (required)
evidence	Typed evidence citation; see supported evidence below.	Object (optional, default `null`)
asset	Asset registration with `id` and `version` for this goal. A newer version supersedes the previous one.	Object (optional, default `null`)
finding	Finding to preserve as an attributed note; requires `evidence`.	String (optional, default `null`)
waive_reason	Non-empty reason a person decided to waive the goal.	String (optional, default `null`)

The evidence kinds in this slice are:

`evidence.kind`	Required citation fields	Server check
`prover_grade`	`grade_run_id`, `diff_hash`	Re-reads a succeeded `spec_conformance` grade and its comparison with the noting person’s Prover access. The grade must name that `diff_hash`, have a `spec_hash`, have verdict `verified`, `not_verified`, or `verified_with_indeterminate`, and not be reopened. It passes on its own only when the review page reads the grade as Verified. Otherwise, a verified person’s review-page acceptance can meet the goal when it covers every item that kept this same grade’s comparison off Verified. For a partially specified grade, that includes every open clause; an unreadable seal cannot pass on acceptance.
`databricks_run`	`databricks_run_id`	Not a hand note. A notebook published under the project with `foundry_publish_notebook` is registered on `rebuilt_and_ran` by Genesis, and each `run_notebook` of that notebook on the same connection is filed under the project and recorded there by itself once the run ends. A run counts only when it succeeded, every task ran the published notebook, and it started after that publish; it certifies that the notebook ran, not what it wrote. A failed run is recorded with “Last run failed” and its reason, and the goal reads unmet until a later run succeeds. Publishing the notebook again makes the goal stale for that pipeline until a run of the new notebook is recorded. A citation of a filed run behaves like a citation of a filed copy. A run Genesis did not file under this project, including one cited by its job id, stays unverified.
`foundry_copy_receipt`	`copy_receipt_id`	Not a hand note. Genesis records every copy filed under the project on `landed` by itself once the copy has ended, checking that the table holds that copy with Foundry’s row count. The note says when the copy was checked; that verdict is the table as it was then, and a recorded copy is not checked again. A citation of a filed copy’s receipt, alone on `landed` with no `asset` or `finding`, writes no note: for a copy not yet recorded it asks that the copy be recorded with its next check’s verdict, normally within a minute, and for a recorded copy it answers with the verdict and `checked_at`. Either way it returns `recorded_by_server`, `state`, `reason` and `message`. On another goal, or with an `asset` or `finding`, it is refused. Registering a dataset that has a filed copy as an `asset`, in any note including a waiver, is refused. A receipt Genesis did not file under this project stays unverified.

Genesis looks for finished, unrecorded copies once a minute and records each one as a note by the server that says when it was checked. A copy still running is not checked until it reports how it ended. A check that cannot answer yet (for example, a stopped SQL warehouse) is tried again later. An older copy whose table now holds a newer copy filed under the same project reads as replaced and does not count. A table that no longer exists, or that holds a copy which failed, is recorded as failed. See Databricks connection setup for connection and warehouse access requirements. For palantir_databricks, register each asset other than a filed copy or a published notebook against the goal it belongs to in an earlier note before citing it. The goals have no fixed input assets, so evidence can only match an asset registered to that same goal at its current version: prover_grade matches the asset version to diff_hash. A project opened by planning expects rebuilt_and_ran to cover every pipeline the plan can translate; a pipeline it cannot translate is listed as a gap. If more than one asset on the goal has that version, include asset_id in evidence to identify the intended asset. For Databricks connection setup and access, see Connect to Databricks and Connections. Only the project owner or an administrator can add notes. Evidence that cannot be checked, does not identify a current asset version, or is not confirmed is recorded as unverified and does not meet the goal. A confirmed passing check can meet the goal; a confirmed failing check records a failed goal. A goal with multiple registered assets is met only when every asset has passed at its current version; any failed check makes it failed, and a new version or newly registered asset makes a met goal stale. This only accounts for registered assets, not assets that should have been registered but were omitted. A waiver must be a separate note made in the authenticated person’s own chat turn; agent, Slack, and Teams turns cannot waive a goal. The result includes the current status, verification, and note id. The first note for a goal added to the project type after a project was opened also reconciles that goal into the stored project. A prover_grade accepted this way is recorded as passed on a person’s acceptance, not on the grade alone; the note names the accepting person or people and the accepted items. Acceptance must belong to the cited grade’s run and population, so an acceptance for an earlier grade does not count. If the review outcome cannot be read, the citation stays unverified and can be retried. When the grade itself does not read Verified, checking for acceptance also reads the comparison’s review history and, when a verified approval stands, resolves its review population and findings, including an uncapped scan of stimulus records. Approver display names use cached user lookups. A citation of a Foundry copy the server filed runs no warehouse statement and writes no note. It costs one read of the project, one SELECT of the copy’s row, and, when it asks for the copy to be recorded, one UPDATE. The warehouse check runs in Genesis’s recording job: at most four statements on the customer’s SQL warehouse (DESCRIBE DETAIL, SHOW TBLPROPERTIES, COUNT(*) and DESCRIBE DETAIL again), each with a 120-second limit and a session open bounded to about two minutes. A stopped warehouse may start and bill its minimum. After registering current-comparison at version diff_... in an earlier note, add this evidence note:

{
  "id": "proj_...",
  "goal": "proved",
  "evidence": {
    "kind": "prover_grade",
    "grade_run_id": "run_...",
    "diff_hash": "diff_..."
  }
}

`project_read`

Name	Definition	Format
id	Project id. For a Foundry migration it is `project.id` in `foundry_plan_migration`’s answer; for a type opened by hand, the `id` `project_open` returned.	String (required)

Returns the project with its goals, notes, and assets. Current status is computed from the latest asset versions and goal preconditions; only the project owner or an administrator can read the record. The response includes created_at, and goals are returned in the project type’s declaration order.

`get_project_bots`

Parameters

Name	Definition	Format
project_id	Mission id to summarize data agent use.	String

`get_todo_bots`

Parameters

Name	Definition	Format
todo_id	Todo id to list associated data agents for.	String

`_blueprint_tool`

The same tool group also exposes _blueprint_tool for blueprint discovery, lower-level phase operations, import/export, and registry management. Use GET_BLUEPRINT_INDEX and GET_BLUEPRINT_INFO to inspect available blueprints and source options. When the user wants to run a blueprint from chat, call start_blueprint_mission instead of manually executing steps from GET_BLUEPRINT or GET_BLUEPRINT_INFO. The actions below cover rename, upload-to-install, and local-to-managed promotion workflows.

These management actions follow Genesis blueprint-management permissions. In standard deployments, Eve is the agent that runs them.

`action="RENAME_BLUEPRINT"`

Rename an existing custom or remote-backed blueprint using the same backend flow as the Blueprint Library UI. Parameters

Name	Definition	Format
blueprint_name	Current blueprint name. Required.	String
new_name	New blueprint name. Required. Use only lowercase letters, numbers, underscores, or hyphens. Maximum length `100`.	String
blueprint_id	Optional stable blueprint identity for duplicate-name resolution when the same name exists in more than one source.	String
bot_id	Acting agent override. Implicit from the current tool context when omitted.	String
thread_id	Thread context override. Implicit from the current tool context when omitted.	String

Local renames complete immediately. Remote-backed renames return pull-request metadata and become effective after the pull request is merged and the next source sync applies the rename. Genesis rejects the action when the target name already exists, the blueprint is default, or referenced missions are still in flight.

Example

_blueprint_tool(
    action="RENAME_BLUEPRINT",
    blueprint_name="customer_onboarding",
    new_name="customer_lifecycle",
)

`action="INSTALL_BLUEPRINT_FROM_UPLOAD"`

Create a blueprint from a ZIP in the uploads repo using the same validation flow as the Blueprint Library UI. This action is create-only: when the target name already exists locally or in the managed write target, Genesis returns success: false with error_code: BLUEPRINT_IMPORT_NAME_COLLISION (or BLUEPRINT_IMPORT_COLLISION_CHECK_FAILED when collision detection itself fails) and does not overwrite or append a version. Use the Blueprint Library import UI or POST /api/blueprints/import when the operator needs Add as a new version or Replace behavior. Parameters

Name	Definition	Format
upload_path	Path under the `uploads` repo. Required. Use a relative path such as `thread_123/customer_onboarding.zip`.	String
target_repo_id	Optional destination repo ID. Omit it or set it to `blueprints` for the default local install. Set it to a managed git repo ID such as `genesis_blueprints` to install into that repo’s WIP worktree, commit there, and register the managed artifact.	String
target_name	Optional installed blueprint name override. When omitted, Genesis uses the blueprint name from the manifest.	String
auto_register	Automatically register the blueprint after install. Default: `true`. For local installs, this must remain `true`.	Boolean
bot_id	Acting agent override. Implicit from the current tool context when omitted.	String
thread_id	Thread context override. Implicit from the current tool context when omitted.	String

Use target_repo_id for this action, not blueprint_source_repo_id. upload_path must stay relative to uploads/ and cannot contain . or .. path segments.

Example

_blueprint_tool(
    action="INSTALL_BLUEPRINT_FROM_UPLOAD",
    upload_path="thread_123/customer_onboarding.zip",
    target_repo_id="genesis_blueprints",
    target_name="customer_onboarding",
)

`action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO"`

Move a blueprint that is already installed locally into a managed git-backed repo without asking the user to re-upload the ZIP. Parameters

Name	Definition	Format
blueprint_name	Local blueprint to promote. Required.	String
target_repo_id	Managed destination repo ID. Required.	String
replace_existing	Overwrite a same-named blueprint already registered in the target managed repo. Default: `false`.	Boolean
bot_id	Acting agent override. Implicit from the current tool context when omitted.	String
thread_id	Thread context override. Implicit from the current tool context when omitted.	String

Use target_repo_id here too. blueprint_source_repo_id is for the legacy IMPORT_BLUEPRINT flow and is rejected for promotion.

Promotion is only for blueprints currently installed in the local blueprints repo. If the blueprint is already in the target managed repo, Genesis returns a success no-op. If it is already managed in a different repo, Genesis returns an error instead of performing a cross-managed-repo migration.

Example

_blueprint_tool(
    action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO",
    blueprint_name="customer_onboarding",
    target_repo_id="genesis_blueprints",
    replace_existing=True,
)

Use Cases

Managing complex data engineering projects with multiple interdependent tasks
Coordinating team workflows with automated task assignment and progress tracking
Building project documentation and asset libraries with organized file management
Tracking mission progress with detailed work logs and completion metrics
Managing dependencies between tasks to ensure proper execution sequencing
Creating comprehensive project dashboards with data agent assignment and progress visibility
Coordinating cross-functional projects with multiple stakeholders and deliverables

Workflow/How It Works

Create a mission with name and purpose.
Break down work into todos and assign to data agents or people.
Wire dependencies so prerequisites complete first.
Record work as progress is made, attaching outputs and links.
Manage assets at the mission level for easy retrieval.
Scale with bulk create or delete when scope shifts.

Avoid circular dependencies. If A depends on B and B depends on A, scheduling will stall. Use get_todo_dependencies to verify the graph before large changes.

Integration Relevance

file_manager_tools for storing specs, outputs, and evidence.
make_baby_bot to assign specialized agents to todos.
data_connector_tools to link data work directly to tasks.
git_action for versioned assets and code paths.
handoff to orchestrate multi-agent workflows.
slack_tools to notify owners on status changes.

Configuration Details

Status values must match the allowed set for reliable dashboards.
Use for_bot_id when automations act on behalf of a controller agent.
Store returned ids from create calls for subsequent updates and dependency wiring.
Choose asset types that reflect storage location and retrieval method.

Limitations or Notes

Deletions are permanent. Export state before bulk removals.
Very large dependency graphs can be hard to visualize. Document key chains in the mission description.
Bulk operations may take time on large projects. Plan during low-traffic windows.
Data Agent assignment depends on availability and permissions.
Asset references require valid external integrations where applicable.

Output

Task Operations Creation confirmations, detail payloads, and status updates.
Mission Operations Creation confirmations, status changes, and listings.
Work Recording Timestamped entries with descriptions and results.
History Full audit trails of changes and actors.
Dependencies Add or remove confirmations and resolved trees.
Bulk Ops Summaries with success and failure counts.
Assets Created or updated records, listings, and detail views.
Data Agents
Assignment summaries and participation metrics.
Errors Clear messages for invalid ids, status mismatches, or permission failures.

​Overview

​Tool Name

​Purpose

​Key Features & Functions

​Input Parameters for Each Function

​manage_todos

​manage_projects

​start_blueprint_mission

​record_todo_work

​get_todo_history

​get_project_todos

​get_todo_dependencies

​manage_todo_dependencies

​delete_todos_bulk

​create_todos_bulk

​manage_project_assets

​Checked project records

​project_list

​project_open

​project_note

​project_read

​get_project_bots

​get_todo_bots

​_blueprint_tool

​action="RENAME_BLUEPRINT"

​action="INSTALL_BLUEPRINT_FROM_UPLOAD"

​action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO"

​Use Cases

​Workflow/How It Works

​Integration Relevance

​Configuration Details

​Limitations or Notes

​Output

Overview

Tool Name

Purpose

Key Features & Functions

Input Parameters for Each Function

`manage_todos`

`manage_projects`

`start_blueprint_mission`

`record_todo_work`

`get_todo_history`

`get_project_todos`

`get_todo_dependencies`

`manage_todo_dependencies`

`delete_todos_bulk`

`create_todos_bulk`

`manage_project_assets`

Checked project records

`project_list`

`project_open`

`project_note`

`project_read`

`get_project_bots`

`get_todo_bots`

`_blueprint_tool`

`action="RENAME_BLUEPRINT"`

`action="INSTALL_BLUEPRINT_FROM_UPLOAD"`

`action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO"`

Use Cases

Workflow/How It Works

Integration Relevance

Configuration Details

Limitations or Notes

Output