AI engineering is not only about calling a model. It also includes context, tools, workflows, and safety boundaries.
AI Agent
An AI Agent can be understood as an execution layer between user goals and large language model capabilities.
It often includes:
- Understanding the task
- Planning steps
- Calling tools
- Reading results
- Adjusting strategy
- Producing the final answer
For example, a coding agent can search code, edit files, run tests, and explain errors.
MCP
MCP can be understood as a protocol for connecting models to external tools and data sources.
It lets models access:
- File systems
- Databases
- GitHub
- Design tools
- Enterprise knowledge bases
Its value is standardizing tool access instead of building custom integrations for every application.
Prompting
A prompt gives the model task instructions and context. A good prompt usually includes:
- Clear goal
- Input data
- Output format
- Constraints
- Examples
Prompting is not magic. It is mainly about making task boundaries explicit.
Function Calling
Function calling lets a model produce structured arguments that a program can use to call real functions.
Typical flow:
- User makes a request
- Model decides which function is needed
- Model generates arguments
- Program executes the function
- Model continues based on the result
This makes AI systems more controllable and easier to connect to business systems.
Deeper Notes
When reviewing this topic, do not memorize names only. Focus on agent boundaries, tool use, MCP context exchange, prompt structure, and function calling in production systems. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.
- Define which decisions belong to the model and which guarantees must be enforced by code, permissions, and data boundaries.
- Do not treat prompting as the only safety layer; external actions need schemas, audit logs, retries, and human fallback paths.
- Evaluate agents by task completion, recovery behavior, and stable tool selection, not only by fluent single-turn answers.
In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.
Practical Checklist
- Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
- Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
- Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
- Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
- End with one sentence about tradeoff: what it gives up and what it buys.
Self-Check Questions
- What core problem does this topic solve?
- What alternatives exist, and what are their costs?
- Where are the most likely edge cases?
- How would code, tests, or monitoring prove that it is reliable?
Applied Scenario
A useful way to understand this topic is to imagine an agent that organizes material and calls tools. The user provides a goal, the model decomposes the task, and the tool layer searches, reads files, calls APIs, or writes results. The hard part is not making the model produce a plan; it is controlling what it can access, what it can execute, how failures are rolled back, and how outputs are verified. MCP helps expose external context in a standardized way, while function calling turns model intent into constrained function arguments.
Common Pitfalls:
- Treating an agent as unlimited automation without task boundaries.
- Optimizing prompts without designing tool permissions and recovery.
- Letting the model decide high-risk actions such as deletion, payment, or publishing.