agentera/agently-request

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
• VLM image questions, local image files, image URLs, or multi-image input -> use .image(question=..., file=...|url=...|files=[...]|urls=[...]); keep .attachment([...]) for low-level rich-content passthrough or exact mixed-content ordering
• 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
• for VLM image requests, prefer .image(question=..., file=...|url=...|files=[...]|urls=[...]); use .attachment([...]) only when the caller already owns provider-style rich content blocks
• 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