# Developer Guide
Generated: 2026-11-02T05:40:31.416Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: integrations.developer-tools
title: Developer Guide
summary: Choose REST, application SDKs, terminal tools or MCP for your Teammately workflow.
kind: reference
product_area: developer_tools
status: stable
updated: 2026-10-31
canonical: /docs/integrations/developer-tools
---
# Developer Guide
## Definition
Choose the interface for the work you want to do. Application ingestion, local source packaging and documentation retrieval have different responsibilities.
| Goal | Interface | Start here |
| --- | --- | --- |
| Send captured application logs | Python, TypeScript or Go SDK | [SDKs](/docs/sdks) |
| Control HTTP requests directly | REST API | [First API request](/docs/public-api/quickstart) |
| Submit application outputs for evaluation | CLI or REST | [External outputs](/docs/cli/external-outputs) |
| Package a managed Harness | CLI | [Managed Harness](/docs/cli/managed-harness) |
| Give a coding agent product context | Local product MCP | [MCP setup](/docs/cli/mcp) |
| Retrieve these manuals | Docs MCP | [Agent Context](/docs/agent-context) |
| Connect external services | Workspace integration | [Integration guides](/docs/integrations) |
## Ownership
The product MCP reads explicit organization, Project, Benchmark and Version context. CLI commands own source and outcome writes. A host credential source or API key does not become text in a copied task.
Application ingestion uses the approved host secret mechanism and the source destination. It requires no CLI installation or browser/native OAuth login. Submission acknowledgement, memory buffering, durable admission and processing completion retain different meanings.
## Fields, states, or lifecycle rules
SDK ingestion uses an injected credential without CLI login. CLI native login uses an OS credential store. MCP hosts reuse the selected credential without passing secrets in tool arguments.
Keep submission, processing and evaluation completion separate. Preserve returned identities and follow the operation-specific recovery contract. A successful connection check establishes only the check described by that integration.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Work with External Agents](/docs/improve/external-agents)
- [Capture and Inspect Logs](/docs/fieldloop/ingest-logs)
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
{% /related-card-grid %}
---
id: improve.work-evolve
title: Work with External Agents
summary: Copy a benchmark-scoped task for your coding agent to implement and evaluate in your real application repository.
kind: task
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/external-agents
---
# Work with External Agents
External Agents gives your coding agent a concrete improvement task grounded in the selected Benchmark Version. The agent works in your real repository; Teammately supplies the applicable Cases, Policies, Rubrics and recorded results.
## Prerequisites
- A selectable Benchmark Version.
- Access to the application repository and authorization for the intended changes.
- A coding agent connected through the setup supplied with the task.
- An optional reference Run that genuinely represents the application starting point.
## Steps
1. Open **Harness improvement → External Agents**.
2. Select the Benchmark Version. Changing it clears local criterion and reference-Run selections.
3. Focus on the whole Benchmark or choose up to 20 approved and applicable Policy and Rubric Versions.
4. Optionally select one individual reference Run. No Run is silently selected.
5. Choose the allowed improvement direction: supported practices, prompt only, model only, the same model family, or model configuration only.
6. Copy the task, including setup instructions when needed, into your coding-agent conversation.
7. Have the agent inspect the actual repository, retrieve the pinned criteria and Run context, implement the change and evaluate it.
8. Inspect resulting Runs through ordinary Benchmark Evaluations.
The copied task includes the Project Agent Brief when present. Credentials do not belong in that text.
## Execution choices
A Teammately Harness and source upload are optional. Customer-executed responses are the default path for the agent's real application. Managed Harness execution requires a deliberate choice.
The product data MCP supplies read-only context, instructions, results and comparisons. The CLI owns local files and submission operations. The documentation MCP only retrieves these manuals.
Start with [CLI authentication](/docs/cli/authentication) and [product MCP setup](/docs/cli/mcp), then follow [external output submission](/docs/cli/external-outputs) or the optional [managed Harness workflow](/docs/cli/managed-harness).
## Object and state changes
The composer keeps selections locally and copies text. It creates no hosted agent Session, transcript, durable handoff object, automatic code adoption or Harness activation. Later submitted responses or managed execution create their own ordinary Run records.
## Success criteria
- The task preserves the intended Benchmark Version and criteria.
- A selected reference Run is checked against actual code.
- Implementation and comparison use actual pre-change and post-change behavior.
- Accepted responses and candidate identity remain attributable.
## Common failure modes
- Stopping after tool setup or context retrieval.
- Assuming a Harness upload is mandatory.
- Treating copied text as an executed Session.
- Using a reference Run from unrelated code.
- Claiming private agent work before returned artifacts or results exist.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Harness Improvement](/docs/improve)
- [Import External Evaluation Outputs](/docs/benchmark-evaluations/output-mapping)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Project Context](/docs/agent-setup/project-context)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Output mapping troubleshooting](/docs/troubleshooting/output-mapping)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: fieldloop.ingest
title: Capture and Inspect Logs
summary: Configure a source destination, submit captured application records, and distinguish durable admission from processing completion.
kind: task
product_area: fieldloop
status: stable
updated: 2026-10-30
canonical: /docs/fieldloop/ingest-logs
---
# Capture and Inspect Logs
Capture the application facts that explain a behavior question. Keep the original records until their admission is known.
## Prerequisites
- The intended workspace, Project and Fieldloop source.
- Authorization to submit to that destination.
- Actual captured content and stable application event identities.
- Explicit source processing consent where screening is enabled.
## Submit captured records
Use the source's supported submission path with the configured destination. Application-library calls can submit batches and inspect receipts without installing a CLI or signing in through a browser.
Follow the [Python](/docs/sdks/python), [TypeScript](/docs/sdks/typescript) or [Go](/docs/sdks/go) quickstart for a complete batch example, or use the [Fieldloop REST guide](/docs/public-api/fieldloop).
Provide a Fieldloop submission credential through your application's approved secret mechanism. A newly created Fieldloop key grants that capability across its workspace; the sender still identifies the Project and source. Existing more restricted keys keep their restrictions.
Preserve the exact batch content and idempotency key when recovering an uncertain request. A successful admission does not mean every row has completed processing.
## Inspect Logs
Open Logs, choose the intended time range and source, then inspect the original record, relationships and processing state. Captured messages, context, trajectories and feedback remain distinct fields rather than a synthesized replacement for what happened.
Read receipt counts for accepted, duplicate, conflicting and rejected rows. A processed batch can still contain row-level outcomes that need attention.
## Object and state changes
Submission records durable intake and admits processing work. Processing publishes the captured log and its attributable snapshot. Further analysis can create or update Threads separately.
SDK buffering can acknowledge memory before server admission. It is not a disk outbox or a guarantee of crash delivery. Caller-owned cancellation and recovery should preserve the exact source records and batch identity.
## Success criteria
- Records reached the intended Project and source.
- Original content and event identities are preserved.
- Admission and processing outcomes are understood separately.
- Credentials do not appear in logs, reports or copied tasks.
## Common failure modes
- Using a key for another workspace.
- Re-encoding changed content under the same retry identity.
- Treating receipt polling as a new submission.
- Assuming a captured record was analyzed without source consent.
- Treating temporary client buffering as durable admission.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Fieldloop](/docs/fieldloop)
- [Read Fieldloop Threads](/docs/fieldloop/threads)
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Fieldloop Intake and Processing](/docs/troubleshooting/fieldloop)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: admin-console.api-keys
title: API Keys and Delegated Access
summary: Choose the intended credential capability and keep workspace keys, delegated users, and browser access distinct.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console/api-keys
---
# API Keys and Delegated Access
## Definition
Use **Admin → API Keys** to manage workspace-owned credentials. A credential's base capability, optional restrictions and the destination's current permissions determine what a request can do.
## Fields, states, or lifecycle rules
- The UI offers Full Access, Read Only and Fieldloop Submission.
- The full key value is shown at creation; later lists use a masked value.
- Renaming a key does not broaden its access.
- Changing access requires issuing the intended credential.
- Deleting a key removes its future credential path.
- Expiry and project/action restrictions, when supplied, narrow the base capability.
## Fieldloop Submission
A new Fieldloop key has the workspace-wide Fieldloop submission capability. Its application sender still specifies the intended Project and source. Current workspace, destination and source authority are rechecked by the backend.
Future sources in the same workspace do not require copying the key into every source policy. Existing keys issued with narrower Project or source restrictions keep those restrictions.
Supply the key through the application's approved secret mechanism. This ingestion path does not require CLI login, browser authentication or expanded login grants.
## Delegated developer access
External Agents benchmark operations can also use delegated native login with explicit read/write scopes and current project read/manage permission. That user principal is different from an API-key principal.
Browser cookie authentication remains the interactive app path. Do not substitute a browser cookie for a server credential or assume a delegated token is accepted on every API route.
## Scope and safe handling
Use an explicit organization, Project, Benchmark and Version for the operation. Keep the key out of copied agent tasks, source files, Case materials and logs. A stable resource ID is not an authorization grant.
The supported external contract defines endpoint schemas and required capability. An internal route or a visible key-management screen does not establish an unrestricted customer API.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Capture and Inspect Logs](/docs/fieldloop/ingest-logs)
- [Work with External Agents](/docs/improve/external-agents)
- [Permissions](/docs/reference/permissions)
- [Admin Console](/docs/admin-console)
{% /related-card-grid %}