agently-output-control
Agently Output Control
Use this skill when the question is what shape the model should return and how that shape should stay reliable.
The user does not need to say .output(...) or ensure_keys. Requests for stable JSON-like fields, structured reports, or machine-readable sections should route here.
Native-First Rules
- default to async-first response consumption when structured output will be streamed, reused, or served over an async boundary
- prefer prompt-config-owned output contracts such as
.request.outputwhen the schema is stable and shared across a request family - prefer
.output(...)for machine-readable results when the schema is dynamic, exploratory, or easier to keep close to code - prefer
ensure_keyswhen required fields must be enforced - keep output schema explicit when downstream systems, workflow branches, or later model steps consume the result
Anti-Patterns
- do not handwrite JSON post-processors when
.output(...)already owns the contract - do not rebuild a stable shared schema in Python if prompt config can own it once
- do not build custom retry loops for missing keys before checking
ensure_keys - do not default to sync-only result handling when the caller is already async-capable
Read Next
references/overview.md
More from agentera/agently-skills
agently-prompt-management
Use when the user is shaping how one model request or request family should be instructed or templated, including prompt slots, input/instruct/info layering, mappings, recursive placeholder injection, prompt config, YAML or config-file-driven prompt behavior, and reusable prompt structure.
27agently-model-setup
Use when the request is already narrowed to wiring a model endpoint, env vars, settings-file-based model config, `${ENV.xxx}` placeholders, `auto_load_env=True`, or connectivity check for a model-powered feature, including local Ollama, dotenv-loaded DeepSeek or other OpenAI-compatible settings, plugin namespace placement, auth, request options, and minimal verification.
27agently-langchain-to-agently
Use when a migration is already known to stay on the LangChain agent side, including agent setup, tools, structured output, retrieval, and short-term memory.
25agently-triggerflow
Use when the user needs workflow orchestration such as branching, concurrency, approvals, waiting and resume, runtime stream, restart-safe execution, mixed sync/async function or module orchestration, event-driven fan-out, process-clarity refactors that make stages explicit, performance-oriented refactors that collapse split requests, or workflow definitions and chunk-level runtime metadata that must stay visible for debugging and visualization. The user does not need to say TriggerFlow explicitly.
25agently-agent-extensions
Use when the user wants tool use, MCP access, HTTP or streaming API exposure, auto-function helpers, wait-for-key behavior, or optional `agently-devtools` observation, evaluation, and playground integration through Agently-native extension surfaces rather than custom wrappers first.
25agently-migration-playbook
Use when the user wants to migrate an existing LangChain or LangGraph system and the first decision is whether the source problem is agent-side or orchestration-side.
24