How AI is used in TaskForce
TaskForce puts AI in your delivery path. You should be able to see what it does, what it can access, and where human judgment stays required.
What the AI does
Inside a run, AI agents frame the problem, draft the spec, propose an approach, write the API contract and break the work into issues. Every one of these is a draft, produced from your workspace context — a proposal, not a decision.
TaskForce agents vs coding agents
TaskForce agents plan and propose delivery artifacts — they don't write and ship your code themselves. Implementation is delegated to the coding agent you choose — such as Claude Code or Cursor — within the permissions and workflow configuration you provide. TaskForce orchestrates; your coding agent executes.
What the AI can access
Agents only receive the context required for the step they are performing, and only the connectors available to that run. Depending on your configuration, that can include:
- Workspace context
- TaskForce Memory — decisions, constraints and conventions
- Connected repositories
- Issues and projects
- Previously approved artifacts
- Connector-scoped resources
Connector permissions determine what an agent can reach. TaskForce never grants an agent broader access than the credentials and scopes you configure.
What it never does on its own
In governed runs, no consequential workflow step advances without human approval. TaskForce does not let an AI-generated decision become the next stage of a governed run on its own — each checkpoint can be approved, edited, rejected or sent back before the workflow continues. The AI proposes. A named human decides. That gate is the product, not a setting you can quietly turn off.
The path of a proposal
Context in, a proposal out — a human decides
Only an approved proposal becomes the context for what follows. A rejection isn't silently discarded — it stays in the run's audit trail with your feedback, and can shape the next proposal.
Which models run, and where
TaskForce runs on your models. It can run local, open models through Ollama on your own hardware — the default today — or call hosted models (such as Claude or OpenAI). You choose the tier, fast or deep, per run, and an enterprise deployment can restrict runs to local models only. Model choice is a configuration, not a code change.
Your data is not used to train TaskForce models
TaskForce does not use your code, decisions, documents or run artifacts to train its own models. What enters a run stays in your workspace, and self-hosting keeps it on your infrastructure — the memory a run builds is an asset you own, not a corpus we harvest.
When a hosted model provider is used, data handling is governed by that provider and your service configuration. Local models through Ollama keep inference entirely within your infrastructure.
What every model call records
Every model invocation is recorded with its execution context:
- Model provider
- Model identifier
- Workflow step
- Timestamp
- Infrastructure used
- Token usage
- Execution status
- Associated artifact
Depending on your deployment and retention configuration, prompts and outputs may also be retained as run artifacts for review and audit — “logged” does not mean every prompt is kept forever.
Accountability and its limits
AI can be confidently wrong. That is precisely why TaskForce is built around human approval and a full audit trail rather than autonomy: the person who approves a checkpoint is accountable for it, and every approval, rejection and model call is attributable after the fact. You get the leverage of agents without handing them the final say.
Human approval does not make an AI-generated decision correct — it makes responsibility explicit.
Known limitations & risks
TaskForce does not guarantee that an AI-generated proposal is correct, complete or free from bias. A model may:
- misunderstand requirements;
- produce incorrect technical recommendations;
- miss dependencies or edge cases;
- expose sensitive information if connector permissions are misconfigured;
- generate artifacts that need human correction.
Human approval, connector scoping and auditability reduce these risks but do not eliminate them. That is precisely why a person stays accountable at every step.
The controls you keep
- A required human sign-off at every consequential checkpoint.
- Read-only actions can run automatically; anything that writes to a connected system is proposed and runs only after approval.
- Hosted vs local model selection, per step, including local-only deployments.
- Connector-level permissions and per-project access controls.
- The ability to reject or revise any generated artifact.
- A full audit trail — with owner-only audit access.
- Self-hosting, so data and models stay on your own network.
Questions from your security team?
The trust center covers data handling, access, logging and the security roadmap. If something isn't there, ask us.