Build long-horizon agents with Grok 4.7 on Amazon Bedrock

SpaceXAI’s Grok 4.7 is now available on Amazon Bedrock, which offers a choice of foundation models (FMs) from multiple providers. According to SpaceXAI, Grok 4.7 is trained to work longer on more difficult tasks and knows when to check its own work. That matters most for agents, which carry a task through many steps and must verify what they find along the way. An agent that works this way has to do more than look things up. It has to form a candidate answer, check it against what it has learned, and refine it until it fits. Grok 4.7 exposes a reasoning effort setting that controls how much deliberation happens before each response, and for agent workloads a practical question is which level to run. In this post, we build a tool-calling agent on Grok 4.7 and evaluate it on three tasks that require search rather than lookup. The tasks are diagnosing a two-service outage from its alerts, scheduling maintenance under interacting constraints, and choosing an optimal set of migrations under a budget. Each task has exactly one correct answer, verified by brute force. We ran all three at every reasoning effort level, six times each, for 72 agent runs. The agent answered 67 of the 72 runs correctly. At xhigh it answered all 18 correctly, and at low it answered 15 of 18 while using about an eighth of the output tokens. That gives a clear trade-off you can tune per request, and we show how to measure it on your own tasks and how to monitor it in production. We report token counts rather than currency throughout. Token prices change, and the counts are what your own costs are derived from, so a measurement expressed in tokens stays valid. What SpaceXAI reports about Grok 4.7 According to SpaceXAI, Grok 4.7 uses a larger base model than Grok 4.6 and was trained with a longer reinforcement learning run on a harder mix of tasks. This mix is weighted toward problems that take many hours to complete. SpaceXAI reports that the model is better at verifying its own work and at managing longer context. SpaceXAI’s published benchmark results follow that emphasis. The largest reported gains over Grok 4.6 appear in the categories that measure sustained work rather than single-turn answers. Benchmark Category Grok 4.6 Grok 4.7 Terminal-Bench 4.0 Multi-hour terminal work 20.3% 37.6% EEBench Electrical engineering 53.0% 64.0% Harvey Legal Agent Benchmark Legal work 15.8% 19.6% CursorBench 4.0 Longer-running coding 40.4% 46.3% HealthBench Professional Clinical reasoning 48.5% 56.7% AA Briefcase v1.1 Multi-hour office work 1,546 1,657 Source: SpaceXAI, Introducing Grok 4.7 ( https://x.ai/news/grok-4-7 ). Scores are as published by SpaceXAI at the time of the model launch. Benchmarks show how a model performs across standard tasks. For your own workload, the useful next step is to measure on tasks shaped like yours, which is what the rest of this post walks through. SpaceXAI lists a 500K token context window for Grok 4.7, with text and image input and text output. On Amazon Bedrock, the model supports configurable reasoning effort, tool calling, and structured output. How you access Grok 4.7 on Amazon Bedrock Grok 4.7 runs on the bedrock-runtime endpoint and is accessed through a cross-Region inference profile. Two profiles are available: Inference profile Routing Use when us.xai.grok-4.7 Within the US geography You have US data residency requirements global.xai.grok-4.7 Commercial AWS Regions You have no residency constraints and want the widest capacity Cross-Region inference routes requests across multiple AWS Regions, which gives you higher throughput without managing capacity Region by Region. Requests name one of the inference profiles rather than a bare model ID. The model supports the OpenAI-compatible Chat Completions and Responses APIs, and the Amazon Bedrock Converse API. On Converse, reasoning is returned as a reasoningContent block alongside the text block. In inferenceConfig , set maxTokens only, and put model-specific parameters, such as reasoning effort, in additionalModelRequestFields . For the current list of supported Regions, service tiers, and token prices, see the Grok 4.7 model card in the Amazon Bedrock User Guide and the Amazon Bedrock pricing page ( https://aws.amazon.com/bedrock/pricing/ ). Prerequisites An AWS account with access to Amazon Bedrock, and model access enabled for Grok 4.7. Python 3.9 or later, with openai , boto3 , and aws-bedrock-token-generator installed. AWS credentials configured in your environment. Your AWS Identity and Access Management (IAM) identity needs bedrock:InvokeModel on both the inference profile and your account’s default project: arn:aws:bedrock:{region}::inference-profile/us.xai.grok-4.7 or the global. equivalent. arn:aws:bedrock:{region}:{account-id}:project/default . Include both resources in the policy statement. The default project permission is required in addition to the inference profile. Connect to the model For production use, we recommend generating a short-term bearer token from your existing AWS credentials, so authentication stays tied to your IAM identity and no long-lived secret is stored: from aws_bedrock_token_generator import provide_token from openai import OpenAI REGION = "us-west-2" MODEL_ID = "us.xai.grok-4.7" client = OpenAI( api_key=provide_token(region=REGION), base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1", timeout=360, max_retries=0, # retries are handled explicitly, see "Build in retries" below ) Reasoning tokens count as output tokens and draw down max_completion_tokens before the answer text is produced, so size the limit to leave room for both. If the limit is reached during reasoning, the response returns without answer text, so check for empty content in agent code and raise the limit if you see it. Our runs used a limit of 32,768 tokens, which left headroom at every effort level. Grok 4.7 supports four effort levels: low , medium , high , and xhigh . Effort levels can change between model versions, so it is worth confirming them against the service rather than hardcoding a list: def supported_effort_levels(candidates=("none", "low", "medium", "high", "xhigh", "max")): supported = [] for level in candidates: try: client.responses.create(model=MODEL_ID, input="Say OK.", reasoning={"effort": level}, max_output_tokens=2048) supported.append(level) except Exception as exc: if "unsupported_value" not in str(exc) and "invalid_value" not in str(exc): raise return supported print(supported_effort_levels()) # ['low', 'medium', 'high', 'xhigh'] Design tasks that need reasoning Many agent evaluations test diligence: read a record, filter it, add it up. Those tasks are worth having, but to see what reasoning effort contributes, a task has to require search: the answer can’t be read off the data, it has to be proposed and then checked. We built a synthetic environment of 20 services, exposed through seven tools, and three tasks on top of it. Every task has exactly one correct answer, and each is built so that a quick heuristic is not enough to find it. Task What the agent has to do What makes it a reasoning task two_fault_diagnosis Two services failed silently at 03:00 and 12 others raised alerts. Identify the two that failed Failed services raise no alerts, so the answer is not among the alerting services. 190 possible pairs, and only one explains exactly the alerts observed maintenance_schedule Patch eight services over four nights, two per night, under ten constraints and a rule that two services from the same team never share a night 2,520 possible schedules, one valid. The team rule depends on data the agent has to look up migration_budget Choose candidates to migrate that maximize risk reduction within a budget, including transitive prerequisites 53 feasible sets, one optimal. Picking the best ratio first gives a set nine points short of the optimum Four practices keep a measurement like this trustworthy, and they apply to most agent evaluations. State every rule the g