<\/p>\n
An AI agent is an application that can pursue a goal through multiple steps instead of producing only a single response. It may inspect state, choose an action, call a tool, observe the result, and continue until it reaches a stopping condition.<\/p>\n
An agent needs an objective that is specific enough to evaluate. \u201cHelp the customer\u201d is vague; \u201cidentify the order, check delivery status, and propose an allowed next action\u201d is easier to control.<\/p>\n
Agents are one application pattern within the broader workload map in AI-900 concepts overview<\/a>, combining model reasoning with state, tools, and controlled actions.<\/p>\n A language model may interpret the goal and choose among actions, but the surrounding application manages identity, tool schemas, state, policy, retries, timeouts, and logging.<\/p>\n Agent behavior depends as much on application engineering as model capability; the Azure AI Engineer course<\/a> shows that wider implementation responsibility.<\/p>\n State can include the original request, intermediate results, tool outputs, decisions, and progress toward the goal. Without controlled state, an agent may repeat work or lose important context.<\/p>\n Keep state structured where practical instead of relying only on a growing conversation transcript.<\/p>\n Short-term memory may preserve information within one task. Longer-term memory may store user preferences, past outcomes, or reusable knowledge.<\/p>\n Persistent memory creates privacy and correctness concerns. Decide what should be stored, how long it remains valid, and who is allowed to read it.<\/p>\n Some agents explicitly create a plan; others choose the next action dynamically. Planning is useful when tasks require dependencies, but an elaborate plan can add latency and failure modes to a simple workflow.<\/p>\n The goal is controlled progress, not maximum autonomy.<\/p>\n Tools may query data, search documents, call APIs, run calculations, create tickets, or trigger workflows. Tool schemas should make valid inputs clear and reject malformed requests.<\/p>\n Once a model can call external services, interfaces and failure behavior become part of the AI design; AI-102 solution guide<\/a> places those integrations inside the full solution architecture.<\/p>\n A model that can draft text is lower risk than a model that can change production data or send money. Give tools the minimum privileges required and use human approval for high-impact operations.<\/p>\n An agent’s authority ultimately comes from credentials and permissions, not the model’s intent; AWS security specialty overview<\/a> develops the surrounding identity and security controls.<\/p>\n After a tool call, the agent needs a clear result: success, failure, returned data, or another state change. Treat tool output as data that may be incomplete, malformed, or untrusted.<\/p>\n Validate important results before using them as the basis for the next action.<\/p>\n Define completion, maximum steps, time budgets, and failure states. An agent should not continue calling tools indefinitely because a goal is ambiguous.<\/p>\n Safe limits also control cost and reduce the impact of unexpected behavior.<\/p>\n Feedback may come from deterministic checks, user review, task success, or offline evaluation. Use it to identify recurring failure patterns rather than simply storing every interaction.<\/p>\n Provider learning paths may label agent capabilities differently, and the AWS AI Practitioner path<\/a> offers another view without changing the underlying concepts of tools, state, and controlled action.<\/p>\n Agents often depend on queues, APIs, databases, identity services, and observability. Those dependencies create ordinary distributed-system concerns such as retry, idempotency, and partial failure.<\/p>\n Agent execution still depends on services, runtimes, networks, and observable dependencies; cloud-native platform overview<\/a> connects that behavior to familiar platform-engineering concerns.<\/p>\n Do not let the model invent authorization. A tool should verify the caller’s permitted scope independently. Sensitive memory and retrieved data should follow the same access rules as non-AI applications.<\/p>\nThe model is only one component<\/h2>\n
State tells the agent what has happened<\/h2>\n
Memory should have a purpose<\/h2>\n
Planning breaks work into steps<\/h2>\n
Tools connect reasoning to real systems<\/h2>\n
Tool permissions define the real risk<\/h2>\n
Observations close the loop<\/h2>\n
Stopping conditions prevent endless loops<\/h2>\n
Feedback improves behavior<\/h2>\n
Cloud-native architecture still matters<\/h2>\n
Security boundaries should be explicit<\/h2>\n