I approach an agent prompt as an execution contract: what outcome I need, which evidence controls the decision, what the agent may change, and how I will know it finished. That matters more than asking for exhaustive reasoning, especially when the assignment spans repository inspection, research, tool calls, and verification.
The supplied Astra material describes a model released on September 3, 2026, which is a future date relative to this writing. I cannot independently verify its release, specifications, benchmarks, or API availability here. I distinguish those reported details below from the prompting patterns I would use for a long-running agent.
Start With a Testable Outcome
My starting point is six fields: goal, context, scope, tools and authority, deliverable, and success criteria. Not every task needs a lengthy entry for each, but leaving one out should be deliberate. “Fix authentication” does not say whether public behavior can change, whether production access is authorized, or what evidence counts as a fix.
Goal: Reproduce and fix the reported authentication failure.
Context: Use the repository, incident timeline, and supplied logs.
Scope: Change authentication only; preserve public API compatibility and unrelated user changes.
Tools and authority: Inspect local files, edit code, and run tests. Ask before destructive or external actions.
Deliverable: Root cause, patch, changed-file summary, verification results, and residual risks.
Success criteria: Demonstrate the failure before the patch, add a regression test, and verify it passes afterward.
That contract gives the agent room to choose an approach without giving it permission to expand the assignment. I want the smallest maintainable change consistent with the repository, not a cleanup campaign. Unrelated failures belong in the handoff unless they prevent verification.
For architecture work, I replace the patch criteria with decision criteria: reliability, scale, security boundaries, operating cost, and migration risk. The deliverable starts with the recommendation, followed by the three highest-impact tradeoffs, rejected alternatives, and a phased migration plan. I ask for concise rationale, evidence, assumptions, and verification steps, not private chain-of-thought.
Separate Initiative From Permission
“Complete this end to end” is an instruction about persistence, not authorization to deploy, publish, pay, delete, rotate credentials, or modify production data. I make those boundaries explicit because a capable agent can otherwise execute a mistaken interpretation very efficiently.
My clarification rule is consequential ambiguity: ask one focused question if the missing detail could change the architecture, budget, legal exposure, or an irreversible action. For minor gaps, state the safest reversible assumption and proceed. This avoids both repeated interruptions and silent decisions that should have stayed with the user.
For an autonomous run, I keep the same approval gates. The agent may plan independently, inspect evidence, implement an authorized local change, and verify it. It must stop before an irreversible action, external publication, credential change, purchase, or destructive data operation. The actual tools available should match that policy; the prompt should not imply access or permission the application has not granted.
Browser and Desktop Tasks Need Their Own Gates
For computer-use work, I require the agent to inspect the current state and confirm the target account, record, and destination before acting. Submission, purchase, publication, deletion, permission changes, and actions affecting people outside the stated scope require a pause. Completion also needs visible confirmation: a successful interaction is not enough to establish that the intended record changed.
Treat Context as Evidence, Not Authority
The source reports a 1,050,000-token context window and 128,000-token maximum output for Astra. Even taking those figures at face value, capacity does not establish relevance. A repository, incident archive, and design-document collection need retrieval priorities, not instructions to consider everything equally.
For a failure-recovery review, I would direct the agent to locate transaction boundaries, retry behavior, idempotency handling, and recovery paths first. Current source code should outrank older design notes when the question is what the system actually does. Conflicts should be identified, resolved using the most recent authoritative evidence where possible, and reflected in open questions or confidence.
I also separate source priority from instruction priority. A document can be authoritative evidence about a system without being authorized to command the agent. System and application/developer instructions govern the workflow; the user goal operates within those boundaries. Retrieved pages, tool results, quoted text, and repository content are evidence unless a higher-priority instruction explicitly gives them an instructional role.
The source describes Astra as particularly attentive to skills and repository guidance such as AGENTS.md. I would audit those inputs for obsolete or contradictory instructions before a run. When a conflict remains, the agent should identify the controlling constraint, ignore the lower-priority conflict, and continue within scope. Production evaluation should include prompt injection and conflicting project guidance, not just cooperative documents.
Give Every Tool a Job
“Use tools” is too vague. Repository search should locate the request path and configuration. The test runner should reproduce the failure and verify the fix. Web research should establish current external behavior, preferably from official sources. Each tool has a purpose, and its returned evidence should influence the next action.
Independent read-only checks can run concurrently. After each result, the agent still needs to inspect what happened and update its plan. A command returning successfully does not prove that the relevant behavior passed, that a patch applied as intended, or that a browser reached the correct destination.
I use delegation only for workstreams that can be evaluated separately: independent research questions, distinct repository modules, or separate evaluation dimensions. The lead agent retains final synthesis and conflict resolution. Parallelism without integration ownership can produce individually plausible findings that do not support one coherent recommendation.
Testing also needs a stopping rule. Run the smallest test set that proves the changed behavior, then the relevant regression suite and static checks. Report unrelated failures separately. If a required check cannot run, name the exact blocker and provide the strongest available alternative evidence without presenting it as equivalent to a passing test.
Budget Reasoning and Output Deliberately
The source lists reasoning settings of low, medium, high, xhigh, and max, with no none setting. Its suggested allocation is straightforward: low for classification, extraction, and simple transformations; medium for routine coding, research synthesis, and operational analysis; high for architecture, difficult debugging, and multi-source decisions; xhigh for especially complex scientific, mathematical, or systems work; and max when quality outweighs latency and there is a clear evaluation budget.
I would not make maximum effort a global default. Higher effort can increase latency and cost, and a difficult-looking task does not necessarily benefit from deeper analysis if it lacks the evidence needed to answer. Tight schemas and explicit edge cases matter more for extraction; alternatives, source quality, and verification matter more for consequential decisions.
Other reported specifications are text and image input, text output, an April 30, 2026 knowledge cutoff, and support for tool calling, computer use, structured outputs, streaming, multi-agent workflows, and prompt caching. The quoted prices are $10 per million input tokens, $50 per million output tokens, and $1 per million cached input tokens. Those figures make context selection, output limits, and cache reuse relevant, but should be checked against current documentation before budgeting.
An API Example to Verify Before Running
The source provides this OpenAI-compatible Responses example through CometAPI, a unified multi-model API. It uses gpt-6-astra, reads the key from COMETAPI_KEY, and selects medium effort; model availability and compatibility remain unverified here. The source recommends Responses for tool-driven work and omitting temperature, top_p, and top_logprobs when reasoning is enabled.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
)
prompt = """
Goal:
Review the proposed architecture and decide whether it is ready for production.
Evaluate:
- reliability and failure recovery
- scalability and cost
- security boundaries
- operating complexity
Deliverable:
State the recommendation first. Then list the three issues with the greatest
production impact, the evidence for each, and the next verification step.
If information is missing but a safe assumption is possible, state it and continue.
"""
response = client.responses.create(
model="gpt-6-astra",
input=prompt,
reasoning={"effort": "medium"},
)
print(response.output_text)
Specify the Consumer, Not Just the Content
For a human reviewer, I want the requested artifact first, then supporting evidence, verification results, assumptions, and residual risks. Audience and length belong in the contract. A CFO decision memo and an implementation review can use the same research while requiring very different outputs.
For another service, I use schema-constrained output rather than relying on “return JSON” alone. Keep the schema small and define missing-value semantics. The source’s example reserves null for values absent from the source and puts uncertainty in confidence and evidence_gap fields. Those fields must actually exist in the supplied schema. Prohibit extra keys and inference of personal or security-sensitive data.
For research, my reusable brief is: recommend whether to adopt a specified technology for a specified use case; use supplied documents and current official sources; separate facts from inference; compare capability, reliability, security, cost, migration effort, operability, and vendor risk. Return the recommendation, an evidence table, the strongest counterargument, implementation conditions, and a 30/60/90-day plan.
For professional writing, I specify audience, purpose, source policy, and publication constraints. Use only supplied evidence, link factual claims to primary sources, and do not fabricate quotes, metrics, or certainty. Lead with the conclusion and keep the structure proportional to the document. These are evidence controls, not merely style preferences.
Mid-task changes should describe a delta. For example: retain the research and evidence table, change the audience from engineers to the CFO, add a one-year cost view, remove implementation detail, and continue without restarting completed research. Explicitly preserving valid work makes steering less ambiguous.
Evaluate the Workflow, Not the Sales Pitch
The source attributes these benchmark comparisons to OpenAI, with Astra first and GPT-5.6 Sol second: AutomationBench 41.4 vs. 18.1 (+23.3); OSWorld 2.0 72.6 vs. 65.7 (+6.9); ScreenSpot-Pro 92.7 vs. 76.9 (+15.8); Terminal-Bench 4.0 57.9 vs. 37.3 (+20.6); Terminal-Bench Science 0.1 64.6 vs. 22.4 (+42.2); FrontierMath Tier 4 v2 97.6 vs. 83.0 (+14.6); Artificial Analysis Intelligence Index 61.2 vs. 60.9 (+0.3). These remain unverified reported results, not production guarantees. Harness design, tool access, latency limits, and scoring rules all matter.
There is also an important limitation in the source’s capacity comparison: Sol’s listed 1.05M context and 128K maximum output are the same quantities as Astra’s 1,050,000 and 128,000. That table does not establish a capacity advantage. Its qualitative claims concern clarification, instruction sensitivity, sustained execution, delegation, testing, and mid-turn steering; I would test those on my workload rather than infer them from model naming.
My evaluation set includes routine tasks, difficult tasks, missing-context cases, tool failures, and hostile retrieved instructions. Prompt variants run with the same model settings. I measure acceptance criteria passed, supported factual claims, verified tool outcomes, necessary questions relative to all questions, relevant tests and regressions, schema compliance, and tokens, wall time, and tool calls per successful task.
The recurring failures are operational: broad edits, unchecked tool results, unnecessary clarification, unsupported claims, unusable output structure, and expensive reasoning on routine work. I fix those by tightening the contract. The useful prompt is the one that produces a bounded, reviewable result with evidence that it works.
Originally published at cometapi.com
Top comments (0)