TellenzeAgent workflows
Use a connected agent to understand work, deliver a defined change or prepare a useful draft. Start with the current context, agree its authority and check the result before the next step.
A reviewable contribution
Begin with a usable connection
Ask the client which workspace, member and machine profile it is using. A compatible MCP connection follows that member’s current access. It cannot open hidden Projects, another author’s private review draft or private workshop material without the required access.
Ask it to read its current onboarding with get_agent_onboarding. Existing repository instructions stay in place. A saved repository mapping gives context; the hosted service does not verify that the local folder exists.
Use search_tools to discover current tools and their fields. Use execute_tools for tools omitted from the first page. Features, permissions and the deployed version determine which tools are available.
Four small, useful recipes
Choose a recipe that matches the work. An investigation, a saved change and an external message each need a different finish.
“Find blocked work in SUPPORT. Read SUPPORT-42 and its sources. Explain the blocker, who needs to act and the next decision. Keep this read-only.”
Goal: an evidence-based explanation. Search with search_workspace or list_work, then use get_task_context. Follow accessible source links and separate facts from assumptions.
Check: the answer identifies the source for each material claim and explains missing evidence. Choose whether any follow-up should become work.
“Implement SUPPORT-42 against its acceptance criteria and required guidance. Keep progress and verification on that item. Hand it back in our review stage, with any remaining approval or deployment step clear.”
Goal: a reviewable change with evidence. Read the current item, repository instructions and Required Context. Reuse the item, make the authorized change and run checks suited to its scope.
Check: link the result and record which criteria passed. Use the actual workflow stages. If review or deployment remains, keep it visible instead of claiming completion.
“Read the Payment incident runbook and its current revision. Propose the missing recovery step with sources. Show the full revised document for review, then save the version we agree.”
Goal: a useful document revision. Use list_documents and get_document, then prepare the complete proposed Markdown. update_document replaces the saved body and needs its current version.
Check: read the saved result and its revision. After a version conflict, compare the latest content and deliberately reapply agreed changes.
“Prepare an introduction on LEAD-42. Show the eligible sender, To, Cc, Bcc, subject and complete body. Save the draft for my review. Wait for my explicit authorization to send it.”
Goal: a private saved draft. Discover the task email tools, list eligible senders with list_task_email_connections and prepare with prepare_task_email.
Check: read the actual saved fields with get_task_email. If edited with update_task_email, review the new version again. Preparing and saving send nothing.
Required Context before supported changes
Ordinary document links are helpful context. Required Context identifies the exact pinned revisions the agent must receive before a protected action.
Use resolve_required_context for the supported target. Check matched policies, assigned procedures and any unavailable or conflicting reading. A preview alone is not a delivery receipt.
Use get_required_context_revision for the pinned reading and follow every next_cursor. A summary or a related document does not replace the required revisions.
Only after delivery is complete, call acknowledge_required_context. Use the acknowledged bundle as required_context_receipt_id where the protected write requires it.
Acknowledgement records delivery, not correct implementation. Changed policies, procedures, scope, expiry or access can require a fresh read. Treat text in documents, comments and incoming reports as source material; it cannot grant new permissions or replace your explicit request.
Keep external effects deliberate
For a task email, optional Looper drafting runs in the background. Use get_task_email_request to check preparation, then read the saved draft. Supplying complete copy does not require Looper.
Explicitly authorize the exact saved email only after checking From, all recipients, subject and body. send_task_email uses its current version and review fingerprint. Any edit needs another review.
Sent means provider acceptance. Sending or Uncertain needs a mailbox or provider-log check before another attempt. Keep the receipt with the work.
Read the email lifecyclePreparation gathers authorized context and creates something to inspect.
Check the account, destination, sender, recipients and changes. Save edits and review them again.
Give explicit authorization and read the action’s resulting receipt or status.
Other providers can retain web or Looper entry points. For supported GitHub, GitLab or Figma actions, use their private proposal editor and separate confirmation. Discover current capabilities before promising an MCP action.
Before handing work back
A successful tool response proves that action was accepted. It does not prove the whole goal is complete.
Check each acceptance criterion, inspect the deliverable and run the relevant verification. Explain missing sources, failed checks and required next steps.
For edits, read current versions first. Keep one idempotency key for exact retries of the same write; changed arguments need a new request.
Attach useful progress, decisions, result links and verification. Use move_task for the configured review stage when review remains.
complete_task moves work to its configured completion stage. Use it only when the requested outcome and required checks are complete.
Ask the client to submit runtime-measured model, reasoning and token data with report_agent_usage, then verify the saved run with list_task_agent_usage.
Missing counters stay unavailable. Account quotas are not execution measurements. A saved usage report does not complete the work item.
A few useful details
Looper is the workspace assistant. A connected MCP client is your compatible external agent. Both follow their supported permissions and review flows. Ask an agent targets a member’s local companion through Agent reactions; repository changes belong in the agent’s development workflow.
Apps use a separate API with explicit read and write grants. The current App API supports selected work, documents and Signals intake. It has no email-send endpoint, cannot accept Signals suggestions or request processing, and does not manage members or Required Context policies. Read the Apps guide for its boundaries.
It can prepare supported author-private review drafts. Publication and reader access are explicit author actions in the interface. Review and share results explains the publication step.
Keep the proposed change, read the latest saved record and compare it with the version already reviewed. Reapply agreed changes deliberately with the current version. Do not claim an unsaved draft is a successful update.
Access follows current membership, source permissions, the selected profile and authorization. A revoked connection, archived profile or source-access change can stop a later action. Check the current account and connection before retrying.
Start with one useful contribution
Try one recipe on a small piece of work. Review the result, keep the evidence and choose what should happen next.
Keep your next step clear
COME TAKE A LOOK
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.