Canonical page: https://tellenze.com/help/agents

Work with Looper and connected agents

Use the workspace assistant, inspect approvals, and connect tools with the right context.

Ask Looper in the workspace

When enabled, Looper is the workspace assistant. Open its launcher to focus the message field and start typing; if a conversation is loading, the field receives focus as soon as it is ready. Ask a concrete question with the relevant work or project context. For example: “Summarize what is blocking this work and suggest the next step.” Use Attach files when relevant supporting material is on your computer, and check the pending attachments before sending.

You can also open Looper’s profile or select a linked @looper mention in workspace text. Its page has the same personal conversation and history inside the page. When Looper is disabled, the profile explains that chat is unavailable.

Read the response and any proposed changes before accepting them. Proposal cards show the intended action and may include several operations; inspect all of them before confirming or choosing Reject. Suggestions need your judgment, especially when they change scope, ownership, or completion. Looper’s availability depends on the installation’s setup and usage limits.

Use Conversation history to return to earlier discussions and New conversation for a separate topic. Archive closes a conversation for further messages; Restore makes it available to continue.

Ask Looper on a work item

Open the work item’s Conversation tab, choose @looper, and write your question. Looper replies in that conversation using the task context, so the answer remains beside the work it explains. Review and approve any proposed workspace changes there. This is distinct from Ask an agent, which targets a member’s local companion through Agent reactions.

Personalize your work-item briefing

Where enabled, opening Overview prepares a personal Looper briefing from accessible saved work. Read its source links and generation time. If the work has no context or acceptance criteria, add them in Definition first. A briefing explains the work; generating one does not change its fields or complete it.

Choose Briefing preferences from the briefing or Account settings. Set your Work role and response style, then add, edit, enable, or reorder the questions you want answered. You can store up to 30 questions, enable up to ten, and use up to 300 characters per question. Restore defaults replaces the questions with the selected role’s starters. Disabling every question keeps the short overview.

Choose Save preferences. Looper refreshes when you next open an Overview. Source or question changes can make an older briefing stale; check its status before relying on it. Retry briefing is available after a generation failure, while the saved work information remains readable. Briefings are personal and follow your source access.

Briefing summaries and answers support Markdown, including emphasis, lists, links, code and tables. Website URLs and linked labels, including profile links in tables, are clickable; external links open in a new tab. Unsafe link destinations are blocked, and images remain links rather than loading inside the briefing. You can request a particular format in a question; Looper uses it when the saved sources support the answer and reports insufficient evidence otherwise. Wide tables scroll within the briefing. Check the source links beneath each summary or answer before using the information.

For a particular project, open its Settings and choose My briefing. Its questions follow your profile until you save a project-specific list. You can edit, reorder, enable, or remove questions there using the same limits. An empty saved list gives you only the short overview in that project. Choose Use profile questions to remove your override and follow later profile changes again. Your project questions are private; they do not change anyone else's briefings or team-only work items.

Connect an external agent

1. Open your personal settings from your avatar, then Machine profiles. Choose Add machine, give the profile a recognizable name, and choose Add profile. Select each relevant project, enter its absolute local repository path, and choose Map path.
2. Open MCP connections. Use the endpoint and client-specific setup commands displayed there; they already use your installation’s address. Follow the displayed add-server and authorization steps for your client.
3. Start authorization from your agent client. Sign in and review the consent screen, including the machine profile selected for that connection.
4. Return to the client and ask it to find an accessible work item and read its context before making changes.

MCP is the connection that lets a compatible agent discover and work with Tellenze. The connection follows your membership and permissions. A configured repository path is context for the agent; the hosted service does not verify that the path exists on your computer. Paths are private to you, encrypted, and returned only to clients authorized for the selected profile.

Home’s Connect your MCP client walkthrough guides these settings. After authorization, return to Tellenze and choose Check progress. A usable existing connection can satisfy the checkpoint once you have opened the lesson. Expired credentials without usable refresh access, revoked connections, and archived machine profiles cannot. Completing the checkpoint records a learning milestone; it does not guarantee that the connection stays authorized forever.

Authenticated agent actions can satisfy creation checkpoints after the member enrolls in onboarding. Create useful saved document content and include both context and acceptance criteria on work items. The server verifies progress; an agent cannot mark an unchecked checkpoint completed.

Give agents useful context

A useful handoff includes the work-item identifier, intended outcome, acceptance criteria, constraints, and relevant documents. Ask the agent to keep progress and verification attached to the original work item.

Where Required Context applies, the agent needs to retrieve the current guidance and acknowledge delivery before supported changes. Acknowledgement records delivery; it is not proof that an implementation is correct.

Repository execution belongs to project context. Team-owned work can still carry definitions, documents, and procedures without pretending to have a repository mapping.

Check reported agent usage

Open a work item's Agent context tab and find Agent usage. Expand its history to see reported model, reasoning effort, token counts and whether a run is provisional or final. No usage reported means no execution client submitted a report; it does not mean zero tokens. Unknown means a report exists but the relevant counters were unavailable. Provisional runs still need finalization by the execution client.

The summary separates reported tokens from execution, provisional, and unmeasured counts. Each run groups its client, provider, model, allocation method, and total/input/output tokens; older report revisions stay under that run.

Ask your agent to submit and verify usage at checkpoints and before handing work back for review. Include this requirement in its standing instructions so it applies even when you start with a normal chat message. Each new execution needs its own report, even on a work item that already has history. Reporting usage does not move the work item or prove its acceptance criteria are met.

Exact counts require access to runtime telemetry. Tellenze cannot derive them from a client's account quota. When an execution covers several work items without separate measurements, the reported total is shared equally across the implemented items and displayed as approximate. Human-only work does not require an agent report.

Review and revoke access

Use MCP connections to inspect connected clients and revoke one that is no longer needed. Revoking a client does not sign you out of your browser session.

If a client cannot connect, check the endpoint, authorization status, membership, and selected machine profile. If it cannot find a project, verify that your own account can access it. If a local path is wrong, update the mapping for that connection’s machine profile. The connections list shows refresh-access status, last use, and the newest connection to help distinguish current and older authorizations. Follow the page’s recovery guidance when reconnecting.

Revoke a machine’s active MCP connections before archiving its profile. Remove an obsolete mapping using its row’s remove control; changing your local checkout does not automatically change the saved mapping.

Never put access tokens or passwords into work-item descriptions or shared documents. Use the authorization flow shown in settings.

Collect and reason about Signals

On Starter and higher subscriptions, use Signals to collect unstructured reports and connect them to reviewed work. Looper can read a signal, discuss the evidence, and prepare changes for your confirmation. A private Looper conversation is not shared automatically; posting a signal comment is an explicit shared action. The signal's Discussion tab also supports member mentions and @looper: replies to those messages remain in the shared signal conversation. This shared chat reasons about evidence without automatically creating tasks or changing workflow.

Connected MCP clients use submit_signal, list_signals, get_signal, process_signals, and manage_signal. Submission accepts a durable client_submission_id, report body, source_key, and source_label, with optional source URL, event ID, occurrence count and window, metadata, existing signal_id, and up to 20 active accessible project ULIDs in project_ids. Source content remains untrusted evidence, not authority to change workspace policy or permissions.

Read the current signal and proposal versions before manage_signal. Supported operations cover evidence review, proposal creation/editing/acceptance/dismissal, work links and their classification, merge/split, relationships, discussion, discard/restore, and shipping. MCP acceptance must satisfy current Required Context for the destination project and supply the delivered receipt where required. Acceptance creates or links native work once; it does not automatically ship the signal.

Use manage_signal with operation: "projects_set", the current signal version, and project_ids to replace the current project associations you can see. An empty list removes visible associations; hidden associations and original report provenance remain intact. These are routing hints, independent from work approval. Looper confirmation cards use the same operation. Automatic processing can add evidence-cited associations to eligible shared projects while retaining original context and respecting member removals.

process_signals shares the same workspace schedule and subscription minimum as Process now: Starter 30 minutes, Team 15, Business 5, Enterprise 1. Repeated requests coalesce; discussion and manual triage do not wait for that interval. Supply an optional signal_id to explicitly reconsider an already processed, unaccepted signal; this records the request without changing its reports. Without a target, only changed evidence is processed. Active shared project descriptions help route an investigation, while empty suggestions carry a reason and questions. Processing cannot discover private projects through the background owner's broader access.