Communicate technical designs, experimental results, and critical...

Q: In communicating an agentic AI system, what is the core goal beyond listing components, and what four connected communication tasks should a “complete communication task” usually contain?

The core goal is to construct a defensible argument that connects system design and evidence to a practical conclusion (not merely to reproduce technical vocabulary or list what the agent contains). Technical design Explain what components the agent has and how they interact . Experimental results State what was tested, under which conditions, and with what outcome. Critical analysis Interpret what the results mean and identify limitations. Professional delivery Make the explanation clear in both writing and speech.

Q: When explaining how an agent works, what perception–action loop should be described, and which concrete components should the loop be connected to?

Describe the agent as a loop that: Perceives an environment Reasons about it Takes actions Observes the results Repeats until it reaches a goal Connect this loop to concrete components, such as: the language model tools memory planning error handling

Q: What distinguishes “experimental results” from “critical analysis” when communicating agentic system work, and what questions should each part answer?

Experimental results report what happened. Answer: What was tested? Under which conditions? With what outcome? Critical analysis explains what the results mean and how far to trust or generalize them. Answer: What do the results mean? What are the limitations? Together, they help move from evidence to a practical conclusion rather than just presenting numbers or claims.

Q: What makes communication about agentic AI systems “successful” for decision-making, and how should this success criterion shape what you include?

Communication is successful when a reader or listener can: understand the design judge the evidence follow the recommendation This should shape content so you explicitly cover how the system works , why it was designed that way , what the experiments show , and what should happen next —not just what the agent contains.

Q: In professional communication of an agent design, what is the difference between description and justification , and what makes a conclusion “professional” rather than “weak”?

Description : states what the system does . Example: “The agent uses a language model and a file-reading tool.” Justification : explains why it does it (function and constraints). Example: “The file-reading tool gives the agent access to current external data, while restricting it to one directory prevents arbitrary file access.” Weak conclusion : makes an unsupported value claim. Example: “This makes the agent better.” Professional conclusion : states a specific improvement and the tradeoff it addresses. Example: “This design improves task capability while reducing the risk of unauthorized file access.”

Q: For an oral technical presentation of an agent design, what sequence should you use, and why does this ordering help the listener?

Use the same order as the system itself: Goal Input Reasoning Tool calls Observations Final action Safeguards This ordering reduces the listener’s cognitive load because the explanation matches the system’s operational flow rather than forcing the audience to mentally reorder events.

Q: A user asks: “Read data.txt and calculate the average.” What sequence of steps should a multi-tool agent follow, and what extra details should a good technical explanation report about the run?

The agent should: Identify the need for file access based on the request. Call the tool read_file(filepath) to access the file. Parse the returned numbers . Calculate the average . Report the result to the user. A good technical explanation should also state: how many loop iterations occurred, which tools were called , whether the reasoning was correct , and whether anything unexpected happened .

In communicating an agentic AI system, what is the core goal beyond listing components, and what four connected communication tasks should a “complete communication task” usually contain?

The core goal is to construct a defensible argument that connects system design and evidence to a practical conclusion (not merely to reproduce technical vocabulary or list what the agent contains).

Technical design
- Explain what components the agent has and how they interact.
Experimental results
- State what was tested, under which conditions, and with what outcome.
Critical analysis
- Interpret what the results mean and identify limitations.
Professional delivery
- Make the explanation clear in both writing and speech.

When explaining how an agent works, what perception–action loop should be described, and which concrete components should the loop be connected to?

Describe the agent as a loop that:

Perceives an environment
Reasons about it
Takes actions
Observes the results
Repeats until it reaches a goal

Connect this loop to concrete components, such as:

the language model
tools
memory
planning
error handling

What distinguishes “experimental results” from “critical analysis” when communicating agentic system work, and what questions should each part answer?

Experimental results report what happened.
- Answer: What was tested? Under which conditions? With what outcome?
Critical analysis explains what the results mean and how far to trust or generalize them.
- Answer: What do the results mean? What are the limitations?

Together, they help move from evidence to a practical conclusion rather than just presenting numbers or claims.

What makes communication about agentic AI systems “successful” for decision-making, and how should this success criterion shape what you include?

Communication is successful when a reader or listener can:

understand the design
judge the evidence
follow the recommendation

This should shape content so you explicitly cover how the system works, why it was designed that way, what the experiments show, and what should happen next—not just what the agent contains.

When explaining an LLM-based agent’s technical design, how should you structure the explanation as a causal story so that it is clear and professionally justified?

Structure the design explanation as a causal story that follows the system’s operation:

Start with the goal
- State what the system is trying to accomplish.
Describe the components and their order of interaction
- For LLM-based agents, relevant components can include planning, memory, tool use, and action.
- Organize around the loop: perceive, reason, act, observe, repeat.
Give reasons for each design choice
- Explain why each component and constraint exists, not just what it is.
Make error handling explicit
- Do not hide issues like missing files, denied permission, or invalid tool results.

In professional communication of an agent design, what is the difference between description and justification, and what makes a conclusion “professional” rather than “weak”?

Description: states what the system does.
- Example: “The agent uses a language model and a file-reading tool.”
Justification: explains why it does it (function and constraints).
- Example: “The file-reading tool gives the agent access to current external data, while restricting it to one directory prevents arbitrary file access.”
Weak conclusion: makes an unsupported value claim.
- Example: “This makes the agent better.”
Professional conclusion: states a specific improvement and the tradeoff it addresses.
- Example: “This design improves task capability while reducing the risk of unauthorized file access.”

For an oral technical presentation of an agent design, what sequence should you use, and why does this ordering help the listener?

Use the same order as the system itself:

Goal
Input
Reasoning
Tool calls
Observations
Final action
Safeguards

This ordering reduces the listener’s cognitive load because the explanation matches the system’s operational flow rather than forcing the audience to mentally reorder events.

A user asks: “Read data.txt and calculate the average.” What sequence of steps should a multi-tool agent follow, and what extra details should a good technical explanation report about the run?

The agent should:

Identify the need for file access based on the request.
Call the tool read_file(filepath) to access the file.
Parse the returned numbers.
Calculate the average.
Report the result to the user.

A good technical explanation should also state:

how many loop iterations occurred,
which tools were called,
whether the reasoning was correct, and
whether anything unexpected happened.

Why is the agent loop a good organizing structure for communicating an agent design clearly and professionally?

The agent loop is effective because it connects the system into one causal process:

Perception → reasoning → action → observation
- This shows how a request moves through the system, not just what modules exist.
Defined component roles
- It supports explaining both what the agent contains and why each part is necessary.
Supports safeguards justification
- It naturally motivates explaining safeguards such as restricted file access as part of the causal story.

In an experimental report for an agentic AI system, what information must you state to make the evidence reproducible enough for another person to understand what was tested?

An experimental report should specify enough details that someone else can reconstruct what was tested, including:

Models used
Prompt or task definition
Parameter settings (the settings that control model behavior)
Number of runs/trials
Evaluation criteria (how outputs are judged)
Cost, where relevant (so results connect to budget constraints)

When communicating experimental results about an agentic system, what are the four levels in the “setup → observation → interpretation → implication” chain, and what does each level do?

A clear report separates four levels of reasoning:

Setup
- Specifies the task, models, prompts, parameters, and number of trials.
Observation
- Reports what happened, preferably with measurements.
Interpretation
- Explains what the observations suggest (a claim supported by the observations).
Implication
- States what the result means for someone building an agent (a design-relevant takeaway).

A temperature sweep experiment yields the statement “higher temperature produced more varied answers.” Classify this statement (setup, observation, interpretation, or implication), and give one example of an interpretation and one example of an agent-design implication consistent with the material.

Classification: “Higher temperature produced more varied answers” is an observation (it reports what happened).
Example interpretation: Higher temperature may reduce consistency.
Example implication for agent design: A deterministic setting may be preferable for structured tool calls.

These should not be presented as if they were equally certain: an observation is more direct than the downstream interpretation/implication.

Define “valid-output rate” and “correct-field rate” for structured JSON evaluation, and explain why distinguishing them matters when reporting agent results.

valid-output rate = (number of valid outputs) / (total number of trials)
- A valid JSON output has the required syntactic structure.
correct-field rate = (number of outputs with correct field values) / (total number of trials)
- A correct field value is semantically correct (the content is correct).

The distinction matters because an output can be valid JSON but still contain the wrong answer; reporting both prevents an unclear conclusion about whether failures are formatting vs task correctness.

In 20 trials of a structured JSON task, 18 outputs are valid JSON and 16 outputs contain correct field values. Compute the valid-output rate and correct-field rate, and state a professional design-relevant conclusion.

valid-output rate = 18/20 = 0.90 = 90%.
correct-field rate = 16/20 = 0.80 = 80%.

A professional conclusion is that formatting reliability is higher than task reliability, so a tool-using agent still needs validation of the contents (even when the JSON parses).

When reporting experiments for agentic systems, how should “cost” be incorporated into results, and what design discussion does it support under a fixed budget (e.g., $10)?

Cost should be treated as part of the result by connecting token usage and model prices to the number of calls, especially when the task has a fixed budget. Under a $10 budget, the material contrasts approximately:

100 calls to GPT-4o-mini, or
40 calls to GPT-4o, or
5 calls to o3

This supports a design discussion about many cheap calls versus fewer expensive reasoning calls.

Why does a professional report on agent experiments keep measures like valid-output rate, correct-field rate, variability, and cost separate rather than rolling them into a single unclear conclusion?

Because these measures describe different properties of system behavior:

valid-output rate: formatting/syntactic success
correct-field rate: semantic/task correctness
variability: how much outputs change across runs/conditions
cost: feasibility under budget (token usage × pricing × number of calls)

Reporting them separately helps communicate how evidence supports a design decision and transforms raw outputs into an evidence-based explanation of which agent design is appropriate.

In a critical analysis of two agentic AI systems (or two LLMs), what makes the analysis “critical” rather than just saying one is “better,” and what kinds of explicit criteria can you use?

Critical analysis means comparing alternatives using explicit criteria, not making an unsupported overall claim that one system is “better.”

Use explicit comparison dimensions such as:
- Capability (can it solve the task?)
- Reliability (does it solve the task consistently?)
- Cost (is performance affordable at intended scale?)
- Latency and compute (is inference effort acceptable?)
- Context handling (can it use relevant information from long interactions?)
- Deployment (can it run in the required environment?)
- Risk (what happens when the model is wrong?)

When comparing two models’ performance on a multi-step problem, what evaluation setup and failure-focused reporting should a strong critical analysis include?

A strong comparison should:

Use the same multi-step problem for both models, so differences are attributable to the models rather than the task.
Identify where the smaller model fails, not just that the larger model scored higher.
- Examples of failure types include: an incorrect intermediate step, poor instruction following, an invalid format, or inability to use information from earlier context.

What LLM limitations should be considered in a critical report on an agentic system, and what is the expected kind of explanation (not just listing results)?

A critical report should explain how key LLM limitations affect the proposed agentic system, including:

Hallucinations
Context-window constraints
Knowledge cutoffs (outdated knowledge)
Prompt sensitivity
Sycophancy

It should go beyond reporting outcomes by connecting observed weaknesses to their design implications (how the limitation can cause agent errors and what that means for the design).

Why must a critical analysis distinguish benchmark performance from operational reliability, and what kinds of domains make this distinction especially important?

Benchmark performance (e.g., a good average score) can differ from operational reliability: an agent may perform well on average but still be unsuitable if occasional failures are unacceptable, especially in high-stakes settings where errors are extremely costly. The material highlights domains such as:

Medical diagnosis
Nuclear power control

Provide the causal chain that connects “outdated or incomplete model knowledge” to a design response and the intended downstream effect on an agentic system.

Outdated or incomplete model knowledge
Retrieval of current information through RAG or verification through tools
Fewer unsupported factual claims
More trustworthy knowledge-grounded agent

How can self-consistency be used in analysing or designing an agentic system, and what important limitation must be stated when interpreting it?

Self-consistency can be used by generating multiple answers and checking whether they agree, which can help reveal uncertainty. However, the analysis must note the limitation that agreement does not guarantee truth.

If an agent shows a context-sensitivity failure, what type of design response is suggested (and what should the critical analysis avoid claiming as the only fix)?

A context-sensitivity failure can motivate adding retrieval or explicit memory to the agent design. The critical analysis should avoid presenting simply using a larger prompt as the only (or sufficient) response when the underlying issue is context handling.

In professional written communication of an agentic AI experiment, what must the written deliverable enable a reader to do, and what two concrete components are specified in the practical exercise?

A professional written deliverable should allow the reader to reconstruct the argument without seeing the experiment directly.

Specified components
- Jupyter notebook containing code and outputs.
- One-page analysis focused on the implications for agent builders.

What concise written structure is recommended for reporting an agentic AI design/experiment, and what question should each section answer?

Purpose: What question was investigated?
Method: What models, prompts, parameters, and trials were used?
Results: What measurements and representative examples were obtained?
Analysis: What do the results mean, and where are the uncertainties?
Limitations: What was not tested or may reduce validity?
Recommendation: What should an agent designer do?

When producing both a Jupyter notebook and a one-page analysis for an agentic AI experiment, how should their roles differ, and what kinds of content are called out as useful?

Notebook role: Include enough evidence to support the claims.
One-page analysis role: Interpret the evidence rather than repeat every output.
Useful content when it clarifies the argument:
- Tables
- Plots
- Short code excerpts
- Representative failures

For an oral presentation of agentic AI results, what should be prioritized (and why), and what two communication practices are recommended for technical clarity?

An oral presentation requires stronger prioritization because the speaker cannot show every output.

What to focus on:
- The design question
- The most important evidence
- The practical conclusion
Practices for clarity:
- Explain technical terms when they first appear.
- Use a concrete example to make the agent loop visible.

In the example oral presentation sequence (two models on the same multi-step task), what key comparison is made, what decision rule is implied, and what recommendation is given?

Key comparison:
- The larger model made fewer intermediate reasoning errors, but was more expensive.
- The smaller model was sufficient for simple calls; the larger model was preferable for difficult planning.
Implied decision rule: allocate model strength based on whether tasks are routine vs uncertain or complex.
Recommendation: model routing—use the cheaper model for routine work and allocate stronger inference to uncertain or complex tasks.

When integrating communication across written and oral formats for agentic systems, what four elements should the explanation be organized around, and what adaptation principle makes the result clear and professional?

Organize around:
- The design question
- The strongest evidence
- The limitations
- The recommendation
Adaptation principle: use the same analysis in both formats, but preserve detailed evidence in the notebook while a presentation must prioritize the central argument so the work is understandable to both a reader and a listener.

In an exam answer about an agentic system (design explanation, experiment report, or critical analysis), what is the first framing step you should do before describing details, and why?

First identify the intended audience and the decision your communication must support.

This framing sets what technical detail is necessary and what level of explanation is appropriate.
It keeps the answer goal-directed: the design/experiment/analysis should be presented to enable a specific decision, not just to display facts.

What step-by-step structure should a strong exam answer follow when asked for a design explanation, experiment report, or critical analysis of an agentic system?

A strong exam answer can follow this sequence:

State the agent’s goal and the main research or design question.
Define unfamiliar technical terms briefly.
Describe the architecture, experiment, or comparison criteria.
Provide concrete evidence (e.g., error types, success rates, variability, cost).
Explain what the evidence means for the agent.
Address limitations and high-stakes risks.
End with a clear recommendation.

When reporting experimental results for an agentic system, how should you separate observations from interpretations, and what kinds of observations count as “concrete evidence”?

You should report observations separately from interpretations:

Observations (evidence): concrete reported measurements or outcomes such as error types, success rates, variability, or cost.
Interpretations: what those observations mean for the agent (e.g., implications for performance or reliability), stated after the evidence.

In a critical analysis exam answer, how should you treat limitations and high-stakes risks, and how should they connect to the rest of your communication?

You should address limitations and high-stakes risks and explicitly connect limitations to consequences.

After describing the system/experiment and presenting evidence, identify the relevant limitations and risks.
Then explain the consequences those limitations imply for the agent’s use or the design decision.
This supports finishing with a justified recommendation rather than an unsupported conclusion.

What are three common “don’ts” to avoid in an exam answer about an agentic system, and what should you do instead in each case?

Avoid these mistakes and use the corresponding fixes:

Don’t list components without explaining interaction.
- Instead, describe how components interact as a system.
Don’t report a final answer without intermediate failures or reliability.
- Instead, discuss intermediate failures and reliability, not only the endpoint.
Don’t call a model “better” without naming the criterion.
- Instead, state the criterion (and the evidence) used for “better.”

When comparing model choices in an exam answer, what extra dimensions should you include, beyond qualitative statements, and why?

Include cost and scale when comparing model choices.

These dimensions make the comparison decision-relevant rather than purely qualitative.
They help tie the comparison to practical design consequences and a justified recommendation.

How should you structure an oral exam answer versus a written exam answer to make your technical communication clear and professional?

The emphasis differs by format:

Oral answer: signpost the structure explicitly—design, evidence, analysis, recommendation.
Written answer: ensure every claim is traceable to a method or result.

What does a “high-quality” exam answer’s progression look like for communicating about agentic systems, and what does that progression demonstrate?

A high-quality answer consistently moves through:

technical fact
evidence
interpretation
design consequence

This progression demonstrates clear, professional communication of technical design, experimental results, and critical analysis (in both written and oral form).

Why should you use examples when explaining abstract agent behaviour in an exam answer, and where do they fit in the answer flow?

Use examples to make abstract agent behaviour concrete.

They support clarity when you describe the architecture/experiment/comparison criteria and when you interpret evidence.
Concrete examples help connect technical facts and evidence to a reader’s understanding of behaviour and consequences.

How should you connect an agent’s technical design explanation to experimental reporting so that the final recommendation is defensible rather than just descriptive?

Make the agent design a causal story (goal → components/loop → safeguards/why) and then test the parts of that story with a reproducible experiment report (models, task/prompt, parameters, number of runs, evaluation criteria, cost). Report results using setup → observation → interpretation → implication, and ensure the “implication” explicitly answers what an agent builder should change in the design (e.g., add validation, change temperature, add tool verification), not just what happened.

How do you combine structured-output metrics with critical analysis criteria to decide whether an agent is acceptable for a high-stakes domain?

Use structured-output metrics (valid-output rate versus correct-field rate) as evidence about reliability, then interpret them through explicit critical-analysis criteria (reliability, risk, context handling, cost, deployment constraints). If correct-field rate is meaningfully lower than valid-output rate, conclude that formatting is not the main risk; semantic correctness is. For high-stakes domains (e.g., medical diagnosis, nuclear power control), occasional failures can be unacceptable even with good averages, so the recommendation should include mitigations (validation, tool verification, retrieval/memory) or rejection for that domain.

How should “LLM limitations” be integrated into both the experimental results section and the critical analysis section without conflating observation and interpretation?

In results, treat limitation-related phenomena as observations when they are measured or exemplified (e.g., prompt sensitivity, context failures, hallucinated tool outputs, variability across trials). Keep them tied to the setup (task, prompts, parameters, trials). In critical analysis, interpret how those observations affect the proposed agent’s operational reliability and risk, and connect each weakness to a design response (e.g., context-sensitivity failure → retrieval or explicit memory; outdated knowledge → RAG or tool verification; uncertainty → self-consistency with the stated caveat that agreement is not truth).

How do cost and reliability interact when recommending “many cheap calls” versus “fewer expensive reasoning calls” in an agent design?

Use experimental reporting to quantify cost (token usage × model prices × number of calls) alongside reliability evidence (variability, intermediate failures, valid-output and correct-field rates). Then, in critical analysis, apply criteria of capability, reliability, and cost at the intended scale. Under a fixed budget (e.g., $10), the recommendation should justify whether many cheaper calls are acceptable given observed failure modes, or whether fewer stronger calls reduce intermediate reasoning errors enough to improve operational reliability for the agent’s risk profile.

How should the same underlying argument be adapted across a Jupyter notebook, a one-page written analysis, and an oral presentation for the same agent experiment?

Keep one shared argumentative spine: design question → strongest evidence → limitations → recommendation. The notebook preserves detailed evidence (code, outputs, plots/tables, representative failures) so claims are traceable. The one-page analysis interprets that evidence for agent builders rather than repeating all outputs. The oral presentation prioritizes the key comparison, the most decision-relevant measurements/examples, and a clear conclusion, explaining technical terms as they first appear and using a concrete example to make the agent loop visible.

In an exam answer about an agentic system, how do you combine the agent loop structure with the setup → observation → interpretation → implication chain into one coherent response?

Use the agent loop to explain the design causally (goal → perception/reasoning → tool/action → observation → repeat, including safeguards and error handling), then report experimental evidence about that loop using setup → observation → interpretation → implication. Conclude by linking implications back to specific loop components (e.g., tool validation, memory/retrieval, temperature for structured calls) and address limitations and high-stakes risks. This yields a traceable progression from technical design to evidence to recommendation.

Communicate technical designs, experimental results, and critical analyses of agentic systems clearly and professionally, both in writing and in oral presentations

44 important questions on Communicate technical designs, experimental results, and critical analyses of agentic systems clearly and professionally, both in writing and in oral presentations