# Build your personal assistant — AgentCon Singapore 5 November 2026 · 10:00–11:30 SGT · SUTD Build with Codex. Use Linear.app as a second brain for development work. Compare available models with the same issue prompt and criteria. Use these prompts in order, adapt before running, and use fictional task data. Linear issues and the app’s personal tasks are separate records, with no automatic sync. ## 01. Start with a real job 10:00–10:10 SGT Decision: Capture a follow-up task after meeting someone. Why: Everyone can recognise this situation at a conference. It gives us a clear input, a small action, and an outcome we can check. Act as my product-thinking partner. I am building a personal task assistant during a 90-minute workshop. I am a beginner unless I tell you otherwise. Example: "I met Alex at AgentCon. Save a task to send Alex my demo on 6 November 2026." The core job is to capture, retrieve, and complete personal follow-up tasks. First help me define the user, the problem, and a visible success condition. Ask at most one important question at a time. Keep your explanation short and use plain language. Propose the smallest useful version. We will record the development work in Linear, build with Codex, and check the actual app. Linear tracks our features, bugs, and next steps; the app stores the fictional personal tasks we use to test it. No email sending, calendar integration, login, or deployment yet. Do not write code in this step. Checkpoint: - I can explain the problem in one sentence. - I have one example request and one observable success condition. --- ## 02. Give the work a home 10:10–10:20 SGT Decision: Keep the project brief and first feature in Linear. Why: Son uses Linear.app as his second brain for features, bugs, and follow-ups. Here, Linear holds the development work; the task app holds our example personal tasks. They have different jobs and do not automatically sync. Help me turn our personal task assistant brief into a small Linear project description and first feature issue. Inspect the current project folder before proposing implementation changes; do not overwrite existing work. Required app functions: add_task, list_tasks, complete_task. Task fields: id, title, due_date (YYYY-MM-DD or empty string), status (open or completed). Store example personal tasks in localStorage in this browser. Show a clear message if storage cannot be read or written. Do not silently erase existing tasks if stored data is invalid. Due dates do not create notifications. Draft a project description with the user, problem, intended outcome, and scope. Draft one feature issue with a clear title, context, included behaviour, and acceptance criteria for adding a task, retrieving it after refresh, and completing the correct task by ID. Keep accounts, backend services, external messages, and cloud sync outside the exercise. Return text I can copy into Linear; no API setup is required. Only use a connected Linear tool if it is authorized, available, and appropriate to my explicit request. Never claim an issue was created or updated without verifying the result. If access is unavailable, keep the draft and say so. Linear tracks our development work, not the app’s example personal tasks. Checkpoint: - The brief says where app data lives and what refreshing should do. - The first feature has observable acceptance criteria. - I know whether the issue is saved in Linear or is still a local draft. --- ## 03. Build one working slice 10:20–10:40 SGT Decision: Build the form, task list, and persistence from the issue’s acceptance criteria. Why: A clear issue keeps the request focused and gives us a shared stopping condition. A convincing screen is not proof that data survives refresh. Implement the first feature from the Linear issue brief I provide below. Use the copied description and acceptance criteria as the source of scope. If I provide only a link that you cannot read, ask me to paste the issue text; do not invent its contents. Use the existing project stack if there is one; otherwise choose a minimal local web app. Build a readable, keyboard-accessible interface with a title field, optional due date, Add task button, task list, and Complete action. Label all inputs. Show empty, success, and error states. Render task titles as text, never executable HTML. Create shared functions for add_task({title, due_date}), list_tasks({status}), and complete_task({task_id}). list_tasks accepts open, completed, or all. Generate stable IDs; complete by ID, not by title. Return structured success or failure results. Reject empty titles, impossible dates, invalid statuses, and unknown task IDs. Completing an already-completed task must be harmless. Persist in localStorage. Preserve existing data and report unavailable storage or corrupt data visibly. Do not claim success if saving fails. Keep due dates as date-only values. Do not add a model API, paid service, login, or backend to the app. Explain how to start locally. Run checks for add/list/complete, invalid input, and persistence failure. Report evidence for each acceptance criterion and identify remaining browser checks. Draft a concise Linear update; do not mark the issue complete while required checks remain unverified. Checkpoint: - A saved task survives a page refresh. - Completing a task changes the correct record. - Invalid input produces a useful error without losing tasks. --- ## 04. Build your second-brain workflow 10:40–11:00 SGT Decision: Capture, prioritise, hand off, verify, and record the result in Linear. Why: Linear provides a home for features, bugs, and next steps. Clear issue context makes the next coding session easier; evidence makes the status meaningful. Help me use Linear as a second brain for this project. The task app stores example personal tasks; Linear tracks the development work needed to improve that app. Do not promise automatic sync between them. From the observations I provide, draft one feature issue and one bug issue. For the feature, include the problem, desired outcome, scope, and observable acceptance criteria. For the bug, include expected behaviour, actual behaviour, exact reproduction steps, environment when relevant, and evidence. Do not invent a failure or its cause. If we have no observed bug, label the exercise "Hypothetical practice issue — not a confirmed bug". Recommend which single issue to tackle next and explain the impact and effort in plain language. Produce a self-contained brief I can paste into Codex, including the acceptance criteria and constraints. No API setup is needed. Only read or write Linear through connected tools when they are available, authorized, and requested; otherwise use copy/paste and distinguish drafts from saved issues. After the selected change is implemented, help me verify it in the actual app. Draft a short issue update with the change, checks run, results, and remaining work. Do not mark it done merely because code was written. If a check is blocked or failed, record that accurately and keep the issue open. Checkpoint: - The feature and bug drafts contain enough context to act on; hypothetical examples are labelled. - We selected one bounded issue and handed its full brief to Codex. - The recorded result and status match the verification evidence. --- ## 05. Try to break the promise 11:00–11:15 SGT Decision: Test the real flow and turn demonstrated failures into useful issues. Why: A happy-path demo misses invalid input, duplicate titles, unavailable storage, and small-screen problems. Recording exact evidence helps the next fix start in the right place. Review our actual task app against the selected issue’s acceptance criteria and the checks below. Use synthetic data and preserve existing stored tasks. Ask for pasted issue context if the Linear link is inaccessible. 1. Add a valid task, refresh the page, retrieve it, and complete it by ID. 2. Reject an empty title and an impossible date without changing stored tasks. 3. Add two tasks with the same title; completing one must leave the other open. 4. An unknown task ID returns an error. Re-completing a completed task is harmless. 5. If storage fails or existing data is corrupt, show a useful error rather than claiming success or silently resetting data. 6. Use the form and completion control with a keyboard; labels and focus must remain clear. 7. Inspect a narrow mobile-sized layout for clipped controls, unreadable text, and horizontal overflow. Separate automated checks from actual browser checks. Run the checks available to you, report evidence, and give exact steps for the others. For each observed failure, draft a Linear bug with expected behaviour, actual behaviour, reproduction steps, and evidence. Do not file hypothetical failures as confirmed bugs. Fix the smallest root cause of one demonstrated failure and rerun the affected check. Draft the issue update with passed, failed, and unverified checks. Keep required work open until it is verified; do not claim a Linear update was saved unless it actually was. Checkpoint: - My partner can complete the main flow without my help. - We checked keyboard use, a narrow layout, and at least one failure path. - Linear or our clearly labelled draft records the findings and remaining work. --- ## 06. Compare, then improve 11:15–11:25 SGT Decision: Use one shared issue prompt, judge the evidence, and implement one improvement. Why: A fair comparison teaches more than changing the prompt until one answer looks better. Model names and access vary by account; use the options actually available to you. Use this exact issue brief and the same project context for each model I compare. Do not change files yet. Feature issue: Filter open tasks by an exact selected due date. Context: Our browser task assistant adds, lists, and completes tasks using localStorage. It has validated inputs, stable IDs, and visible storage errors. Acceptance criteria: Selecting a date shows only open tasks due on that date. Clearing the filter restores all open tasks, including tasks without a date. Existing tasks and the add/list/complete flow remain intact. Propose the smallest change, how it fits the current UI and task functions, and the checks that prove the acceptance criteria. Do not add a dependency, backend, paid API, or unrelated feature. State missing context instead of guessing. I will compare responses on correctness, scope control, clarity, and testability using identical criteria. I will record the actual model name shown in my account and observed response time or usage if available. Do not assume a model is available or invent prices. After I select one approach, implement only this issue and verify the new behaviour plus relevant core checks. Draft a Linear update with the result and remaining work. If only one model is available, describe this as a single-model review. Do not mark the issue done until its required checks pass. Checkpoint: - We used the same issue prompt and criteria for both models, or recorded that only one was available. - I added at most one improvement and can explain its value. - The original flow still works and the issue update reflects the checks. --- ## 07. Leave with evidence 11:25–11:30 SGT Decision: Keep a short handoff with issue links, test evidence, and next steps. Why: You should be able to return next week, run the project, and find its unfinished work without reconstructing the workshop. Write a concise README and project handoff based on the actual task app and checks we ran. Include what it does, exact local start instructions, the three task-function contracts, where personal tasks are stored, and the manual acceptance checks. Include the real Linear project and issue links when available; use clearly labelled local draft references if the issues were not created. Do not fabricate links, issue IDs, or saved updates. Separate implemented features, automated test results, and real browser checks. Mark anything not tested as unverified. Record the model-comparison issue prompt, criteria, actual model names, observed outcomes, and reason for choosing an approach. If no comparison happened, say so. Explain that Linear tracks development work while localStorage holds the app’s example personal tasks, with no automatic sync promised. Explain browser-local storage limits and that due dates do not send reminders. List the next three practical issues, starting with the highest-value one, and distinguish drafts from saved issues. Do not describe the prototype as production-ready or mark unfinished work complete. Checkpoint: - I can restart my project using its README. - I can find its next steps and distinguish verified work from unfinished issues. ## Optional extension: LangSmith traceability Inspect my actual project and identify the agent runtime and tool execution path. Add optional LangSmith tracing using the supported integration for that runtime. For the AgentCon Python starter, keep the OpenAI Agents SDK and use OpenAIAgentsTracingProcessor. For a LangChain or Deep Agents app, use its supported LangSmith integration. If this is still a browser-only task app, explain that it has no agent run to trace yet; do not add a backend or model API just for telemetry. First check whether the tracing dependency extra, app/tracing.py, and scripts/check_tracing.py already exist. Reuse and verify working integration before adding anything. Keep existing features, confirmation rules, and private tracing exclusions intact. Configure export on the server through the private .env or deployment environment. Never request or expose an API key in chat, browser code, or Git. Use one LangSmith destination: a project, or a registered agent and environment, with the matching regional API endpoint. Keep tracing optional and inputs/outputs hidden by default. Use pseudonymous conversation IDs and record the deployed prompt/tool version. Capture model and tool spans, timings, token usage where available, and outcomes. Distinguish a returned tool error, a pending confirmation, an SDK-caught exception, and a run interrupted after a write. A completed run is not proof of booking or delivery. Export failures must not break the assistant. Add or run a synthetic export-and-readback check with no model calls, calendar changes, or messages. Verify a finished root and its nested tool in the selected LangSmith destination. Explain how to restart the app to load changed settings. Keep any missing credentials or failed readback explicitly unverified. Then show how to use one problematic trace to draft a Linear issue, reproduce it with a test, improve one prompt or tool, and compare versions before release. Python starter setup (only after confirming the tracing integration exists): INSTALL THE OPTIONAL INTEGRATION uv sync --extra tracing LOCAL .env · APAC EXAMPLE LANGSMITH_TRACING=true LANGSMITH_API_KEY=your-own-langsmith-key LANGSMITH_PROJECT=pippa-workshop LANGSMITH_ENDPOINT=https://apac.api.smith.langchain.com LANGSMITH_WORKSPACE_ID= PIPPA_TRACE_CONTENT=false PIPPA_VERSION=workshop VERIFY SYNTHETIC EXPORT + READBACK uv run --locked --extra tracing python scripts/check_tracing.py RESTART THE LOCAL WORKSHOP uv run --locked --extra tracing python scripts/run_web_local.py Match the endpoint to your LangSmith region. Never combine LANGSMITH_PROJECT with LANGSMITH_AGENT_ID / LANGSMITH_AGENT_ENVIRONMENT. Keep PIPPA_TRACE_CONTENT=false for real user data. Stop the existing local server before restarting. A successful synthetic readback proves export, not production deployment or a real-user outcome. ## Task function contracts add_task Validate and save a task with a clear title and optional exact due date. title: string (required) due_date: string (required; YYYY-MM-DD or empty string) Success: saved task with its ID. Failure: explanation; no false success. list_tasks Return existing tasks matching the selected status. status: string (required; open, completed, or all) Success: matching tasks with IDs, titles, dates, and statuses. An empty list is valid. complete_task Complete the specific task selected in the interface. task_id: string (required; from list_tasks) Success: updated task. Unknown ID: error. Already completed: harmless result. ## Official resources OpenAI — Get started with Codex https://learn.chatgpt.com/docs/quickstart OpenAI — Give Codex a good brief https://learn.chatgpt.com/guides/best-practices OpenAI — Codex in your terminal https://learn.chatgpt.com/docs/codex/cli OpenAI — Project instructions · AGENTS.md https://learn.chatgpt.com/docs/agent-configuration/agents-md OpenAI — Choose a model for the task https://learn.chatgpt.com/docs/model-selection Linear — Create issues in Linear https://linear.app/docs/creating-issues Linear — Organise work with projects https://linear.app/docs/projects LangChain — Trace your agent with LangSmith https://docs.langchain.com/langsmith/trace-with-openai-agents-sdk LangChain — Control what your traces contain https://docs.langchain.com/langsmith/mask-inputs-outputs LangChain — Trace LangChain applications https://docs.langchain.com/langsmith/trace-with-langchain