Application project briefs
AI Developer Projects for a Practical Portfolio
A useful AI developer project solves a defined application problem and makes its behaviour easy to inspect. Build the request flow, check the model's output, test failures and explain the deployment.
Choose a Project for the Skill You Want to Demonstrate
Use fictional records or material you are allowed to process. Keep the first dataset small enough to inspect manually. If the application plumbing is unfamiliar, start with Python for AI Development. For the wider learning order, use the AI Developer Roadmap.
| Project | Main engineering skill | A sensible starting point |
|---|---|---|
| Support Ticket Triage API | Request contracts, structured responses and routing rules | You can write functions and call an API. |
| Version-Aware Documentation Assistant | Retrieval, source versions and answer support | You can build a small backend and manage document metadata. |
| Release Note Drafting Workflow | Multi-step processing, traceable drafts and review state | You can work with JSON records and persistent application state. |
| Tool-Using Service Desk Assistant | Tool boundaries, permissions, approvals and recovery | You can implement and test a state-changing API. |
Four AI Application Project Briefs
Each brief defines the problem, the data boundary, the build, a baseline to compare against, the failure cases to check and what a reviewer should be able to inspect. They are independent practice ideas, not additional promised projects in a SCAI course.
Support Ticket Triage API
Problem. A support team needs an initial category and short summary for each incoming ticket. The application should suggest a routing decision and flag unclear cases for review. Data and boundary. Create fictional tickets with a description and a small allowed category set, such as account, billing, technical and other. Define expected categories yourself. Include ambiguous and incomplete tickets. Do not connect the exercise to a live customer queue. Build. Accept a ticket through a validated API request. Ask a model for a category, summary and explanation, then validate the response against your allowed fields and values. Apply routing rules in application code. Return a review status when the ticket cannot be classified under the rules; do not treat the model's self-reported confidence as a calibrated probability. Baseline. Build a simple keyword or rule-based categoriser. Run it and the model-assisted approach on the same tickets. A model is useful here only if its behaviour justifies the additional dependency for your chosen task. Failure checks. Send an empty description, an oversized request, a ticket fitting two categories, an unsupported category in the model response and a simulated provider timeout. Check that an invalid response cannot silently create a valid-looking routing result. Ready to review. Show the request and response contract, routing tests, category-level mistakes and the path for a person to correct a suggestion. Report classification results separately from API success: an HTTP success response does not establish a correct category.
Version-Aware Documentation Assistant
Problem. A developer asks a question about a specific product version. The assistant must answer from the appropriate documentation and show the passages that support its answer. Data and boundary. Create a small fictional product manual with two versions. Deliberately change one option name or behaviour between versions. Give each source a stable document ID, version and access label. Include questions that have no answer in either version. Build. Parse and index the documents with their metadata. Resolve the requested version and permitted document scope before supplying context to the model. Ask for an answer with references to retrieved passages. Verify that cited references exist and assess whether those passages support the actual claims. A vector similarity score alone does not establish that support. Baseline. Start with keyword search and a source excerpt. Compare it with your retrieval-and-generation approach using the same questions and version constraints. Add reranking or a different chunking method only to address a failure you can describe. Failure checks. Ask about the older version, omit a version where the answer differs, request a removed setting, ask an unsupported question and attempt to access a restricted document. Test both retrieval and generated answers; finding the right passage does not guarantee the answer uses it correctly. Ready to review. Present the source snapshot, retrieval results, citation checks and unanswered cases. For a wrong answer, explain whether the problem came from the documents, retrieval, version selection or generation. Keep document identifiers and versions visible in the evidence you show.
Release Note Drafting Workflow
Problem. A software team wants a draft release note from approved change records. Every substantive claim should be traceable to an included change, and a person must approve the draft before publication. Data and boundary. Use fictional pull-request records with IDs, titles, descriptions and a release tag. Include a reverted change, a duplicate record, an internal-only change and an explicitly labelled breaking change. Define which records are eligible for the release. Build. Implement a fixed workflow: validate the records, select eligible changes, group them, draft the release note and attach source IDs. Store the draft, source snapshot and review status. Keep publication outside the model's control. This task can be implemented as an ordinary workflow; a model-directed agent loop is optional and needs a separate reason. Baseline. Produce a deterministic list of approved change titles. Compare whether the generated draft improves readability while preserving coverage and avoiding unsupported claims. Failure checks. Check that the draft excludes reverted changes, does not repeat duplicate records, retains a documented breaking change and does not invent a release date or performance improvement. Put an instruction-like sentence in a record and verify that it cannot override the workflow's inclusion or publication rules. Ready to review. A reviewer can trace the release note back to its source records, edit it and see which version was approved. If the input snapshot changes, the application must invalidate or recheck the earlier approval before publication. Retain the failed cases that informed those rules.
Tool-Using Service Desk Assistant
Problem. A user wants to check a fictional service request and, when appropriate, create a follow-up ticket. The assistant must stay within the user's access and the application's approved actions. Data and boundary. Use a local test service with fictional users and tickets. Give two users separate records. Start with a read-only get_ticket_status tool. Add a ticket-creation tool only after the read and permission checks work. Build. Define allowed tool names and argument schemas. Establish the user on the server and enforce record access in the tool service. Let the model propose a permitted action; application code decides whether it may run. Bound the number of steps, tool calls and total request duration. For a write action, show the exact proposed ticket to the user and record approval for that payload. Persist an operation identifier before executing the write. Make the test service handle repeated requests for the same operation without creating another ticket. If the payload changes, require approval again. Baseline. Build a normal form and a status lookup for the same actions. Compare task completion, mistakes and user effort. Keep the assistant only where conversational interaction adds something useful to that baseline. Failure checks. Request another user's ticket, pass an unknown tool name, change arguments after approval, repeat an approved request and simulate a timeout after a ticket was created. Reconcile the recorded operation before retrying an uncertain write. Do not assume that a missing response means the write did not happen. Ready to review. Show an execution trace with user scope, proposed action, approval, tool result and final status. Demonstrate that blocked actions stay blocked and that repeated requests do not create duplicate records in the tested scenarios.
Evaluate Changes Before You Call Them Improvements
Create development cases while building the application and a separate held-out set for the final comparison. Record expected behaviour before inspecting the candidate's answers. For retrieval projects, the source documents may legitimately contain the answer evidence; keep the held-out question-and-answer pairs out of prompt examples and tuning data used to improve the system.
Report task quality alongside completion and failure counts. For a documentation assistant, distinguish correct answers on answerable questions from appropriate abstentions on unanswerable ones. A system that refuses every question should not appear successful because its answers contain no unsupported claims.
For performance, record the model/configuration, input sizes, request count and concurrency. Show timeouts separately from completed-request latency. If the sample supports reporting percentiles, state how they were calculated. Record token usage or estimated request cost only when you have the underlying measurements and pricing assumptions.
Treat permission violations and unintended writes as explicit release blockers for the exercise. An average quality score must not hide them. Passing the chosen cases is evidence about those cases, not proof that every future input is safe or correct.
The following is a test plan, not a table of measured results.
| Scenario | Expected behaviour | Evidence to capture |
|---|---|---|
| Valid request within scope | Complete the defined task with a checked result. | Input, output, source/configuration version and assessment. |
| Invalid or oversized request | Reject it before unnecessary model work. | Validation result and whether a provider call occurred. |
| Missing or ambiguous information | Ask for clarification or return the defined review state. | The missing information and the response shown to the user. |
| Incorrect product version | Use the requested version or ask the user to resolve ambiguity. | Retrieved source IDs, versions and answer. |
| Restricted record | Block access before its data reaches an unauthorised caller or model context. | Redacted access decision and tool/retrieval outcome. |
| Malformed model response | Handle the failure without presenting unchecked output as a valid result. | Validation error category and application response. |
| Provider or tool timeout | End or recover according to the workflow's rules and record the outcome. | Timeout category and the recovery step taken. |
Deploy One Project on AWS
Choose one completed application and deploy it with a model API dependency. One possible setup is a Docker image in Amazon ECR, an Amazon ECS service on AWS Fargate, and an HTTPS endpoint through an Application Load Balancer. This is a suggested learning architecture, not a claim that every project or course requires that exact service combination. See the AWS Fargate documentation for the runtime's role.
Use durable storage for any records the application must retain. S3 can hold source documents and exported evaluation artifacts; use an appropriate database for application records and state that needs queries or transactions. Do not assume a container's local files survive task replacement.
Keep model credentials in a managed secret store such as AWS Secrets Manager. Give the application's task role only the AWS access it needs. Distinguish that role from the execution role used by ECS for tasks such as pulling an image and sending configured logs. AWS documents these responsibilities in its ECS IAM role guidance.
Configure logs with request identifiers and useful failure categories. Avoid storing full sensitive inputs by default. ECS logging to CloudWatch is one way to collect container output. Add application signals for task outcome and dependency failures; process health alone cannot measure answer quality.
Before calling the exercise complete, check HTTPS and authentication, try a failed dependency, restart the application and confirm retained state, and demonstrate how you would return to a previous release. Record resource costs and cleanup steps. Budgets and alerts help you notice spending; configure actual usage limits separately where needed. This deployment runs an application that consumes a model API. Hosting a model on a GPU is a different infrastructure exercise.
Present the Project as Engineering Work
Use a README that follows the application from its purpose to its limits:
- The user problem and the boundaries of the exercise.
- Sample data, its origin and permission to use it.
- Setup commands and required configuration.
- A request walkthrough and component responsibilities.
- The baseline and the change you evaluated.
- Test cases, measured results and failed examples.
- Deployment, recovery and cleanup instructions.
- Known limitations and the next change you would investigate.
Include a short demonstration of a normal request and a meaningful failure. Explain what happens in application code, what the model supplies and where a person makes a decision. If a result has not been measured, label it as planned rather than filling in a convincing-looking number.
For guidance on matching this evidence to your next role, read How to Become an AI Developer. Keep your portfolio description consistent with what the repository and demonstration actually show.
AI Developer Project FAQs
Should I Build All Four Projects?
Start with one that matches the skill you need to develop. Complete its normal flow, failure checks and explanation before expanding the portfolio. Add another project when it demonstrates a different responsibility, rather than repeating the same integration with a new interface.
Does Every AI Project Need an Agent?
No. A classification endpoint or fixed drafting workflow may be clearer with ordinary application control flow. Use a tool-using agent when choosing actions dynamically is useful, and keep its permissions, allowed tools and runtime limits explicit.
Can I Use Claude Code or GitHub Copilot for the Implementation?
Yes. Use them to assist with bounded changes, explanations and test drafts. Review the generated code, run the checks and understand the behaviour you present. A portfolio review should make your decisions and understanding clear, regardless of which tools helped you type the code.
What If I Want a Fine-Tuning or Multimodal Project?
Use the Generative AI Projects guide for broader model and document experiments. The briefs here focus on the application layer: APIs, retrieval boundaries, workflows, tool actions and deployment.
Build AI Applications with Guided Project Reviews
Explore School of Core AI's AI Developer course for its guided projects, mentor reviews and AWS deployment work. The course page lists the programme's actual project commitments, prerequisites and delivery details.