| name | agently-request |
| description | Use when the user is shaping Agently request-side behavior: model setup, settings files, prompt management, structured output, response reuse, streaming consumption, session memory, embeddings, knowledge-base indexing, retrieval, or retrieval-backed answers within one request family. |
Agently Request
Use this skill when the work stays on the request side: provider setup, prompt
contracts, output contracts, response consumption, session continuity, or
retrieval.
If the owner layer is still unclear, start with agently-playbook. If the
request clearly needs branching, waiting, resume, or durable orchestration, use
agently-triggerflow and read this skill only for model-step details.
Route Inside This Skill
- model endpoint, env vars,
${ENV.xxx}, settings namespaces, or connectivity checks -> references/model-setup.md
- prompt slots, prompt config, YAML/JSON prompt files, mappings, or reusable request contracts ->
references/prompt-management.md
- stable fields, required keys, machine-readable output,
.output(...), ensure_keys, or validation -> references/output-control.md
- one response consumed as text/data/meta/stream without re-requesting ->
references/model-response.md
- conversation continuity, memo, chat history, or restore-after-restart ->
references/session-memory.md
- embeddings, Chroma collections, Workspace recall, retrieval, or KB-to-answer ->
references/knowledge-base.md
Native-First Rules
- keep provider settings outside prompt and workflow code; prefer settings files with
${ENV.xxx} placeholders when deployment values differ by environment
- keep stable prompt and output contracts in prompt config when shared across a request family
- use
.output(...) tuple ensure flags for fixed required leaves; use runtime ensure_keys only for runtime-dependent paths
- order output fields from supporting information to final decision. Agently
output schemas are ordered: evidence, assumptions, clarifications, source
notes, calculations to perform, concise rationale, and rule checks should
come before final booleans, verdicts, replies, summaries, or actions.
User-facing rendering may reorder sections for natural reading, but the model
generation contract should keep support-before-conclusion order.
- for grading, judging, evaluation, confidence, trust, usability, relevance, or
quality tasks, ask the model for conceptual levels with explicit definitions
instead of precise numeric scores. Use labels such as high_trust,
moderate_trust, low_trust, excellent, adequate, weak, or failed, and define
each label in the prompt. If downstream code needs statistics, thresholds,
weighting, or index math, map the labels to deterministic numbers in code
after model output; do not ask the model to emit
0.78, 3/5, or 8/10 as
the primary judgment.
- do not ask the model to perform complex, long, or high-precision arithmetic,
derivations, or data transformations directly. Ask it to produce executable
Python, Bash, SQL, or another appropriate calculation plan, run that code with
tools, then feed the original question, code, and observed result back into
the next model step.
- when testing model-owned content, use an Agently model judge with output
control and assert structured boolean rule judgments; avoid keyword,
substring, regex, or snapshot checks as the primary semantic correctness test
- for scenario routing, intent detection, and business classification, use a
model request with an Agently output schema instead of tokenization, word
segmentation, keyword hits, or substring rules. Choose smaller or local models
for simple decisions, and larger models for many labels, dense rules,
ambiguity, or complex returned structures.
- use
get_response() when the same model result must be read multiple ways
- keep Session memory separate from TriggerFlow execution state
- use
workspace.build_context(...) when ordinary multi-turn task work needs a
ContextPack from prior Workspace records; use low-level workspace.search(...)
for debugging or explicit filters
- use
workspace.get_data(...), workspace.links(...),
workspace.latest_checkpoint(...), and workspace.checkpoint_history(...)
when building explicit loops that store structured state and record lineage
- keep retrieval explicit when its results feed a later request or workflow step
- default to async-first response consumption in services, streaming paths, and workflows
Anti-Patterns
- do not handwrite provider HTTP calls before checking native model requester settings
- do not rebuild prompt templates with ad hoc string formatting when prompt mappings fit
- do not handwrite JSON repair/retry loops before using output contracts and validation
- do not re-request the same model call only to get text, parsed data, or metadata separately
- do not hide retrieval inside unrelated prompt code
Read Next
references/model-setup.md
references/prompt-management.md
references/output-control.md
references/model-response.md
references/session-memory.md
references/knowledge-base.md