Custom GPTs: Tailored AI Models for Diverse Tasks

Custom GPTs redefine your ChatGPT experience, enabling the creation of personalized AI models tailored to specific tasks. Whether you strive to optimize your project management workflows, simplify complex legal jargon, or generate captivating marketing copy, Custom GPTs offer a versatile solution to meet your needs.

General
Release date	November 6, 2023
Author	OpenAI
Type	Customizable AI model

Custom GPTs redefine ChatGPT's capabilities, enabling tailored AI models that seamlessly integrate external data sources, catering to personal, corporate, or public requirements without coding skills.

Key Features

Tailored Solutions: Customize AI models for various needs.
Real-World Integration: Seamlessly incorporate external data sources.
Simplified Creation: Build AI models without coding knowledge.

For more details and updates, refer to the OpenAI Blog - Introducing GPTs and explore diverse Use Cases demonstrating the potential of Custom GPTs.

GPTs Tutorials

Agent_Trap_Evals

The problem: agents rarely fail hard questions. They fail chores. They report "backup verified" because the log says success, while the archive is truncated. These false claims slip out during routine work, and a real shell makes them dangerous. What Receipts does: you give it a real task, like checking a backup or triaging a failing build. A control layer plans the work and runs every action in an isolated Vultr sandbox [gVisor pods on VKE]. The sandbox has no secrets, has time and memory caps, and is destroyed after each task. Every command's output, exit code, and files become a receipt. Before any claim reaches you, a verifier checks it against those receipts: did the agent check the layer that matters, or just the easy one? An unsupported claim is blocked and sent back to be verified, or reported as unverified. You get the answer together with its proof. Containment: [demo moment, e.g. the agent runs rm -rf / and the sandbox absorbs it; the host is untouched]. Measured: we score Receipts with agent-trap-evals, an open-source trap set we built before the hackathon from real agent incidents. Verifier off vs. on: [X/Y vs. X/Y caught], [n] false alarms on honest controls. For: platform and DevOps teams putting agents on operational work, where a confident false "done" costs more than a slow answer. Sandboxes like E2B contain actions but don't check claims. Eval tools score offline but don't stop a bad claim at runtime. Receipts does both, live. [Business model; next steps.] All LLM calls use Vultr Serverless Inference.

ConsultPrep AI

Many people arrive at a medical appointment unsure how to describe their symptoms, when they began, what has changed, or how they affect daily life. ConsultPrep AI is an interactive patient-intake assistant designed to help with that preparation. The patient describes their concern in their own words. ConsultPrep keeps track of details already shared, asks focused follow-up questions to clarify missing or uncertain information, and avoids treating unanswered details as facts. Patients can ask what they have said so far and request a draft consultation summary. The draft organizes the patient’s reported symptoms, timing, severity, related symptoms, and daily impact, while making unclear or unreported information visible. Before using it, the patient can review and correct the summary, then bring it to a clinician to support the appointment conversation. The summary is not sent automatically and is not a diagnosis or treatment plan. ConsultPrep aims to make patient-reported information easier to communicate while keeping the patient in control. It is a prototype, not a substitute for professional medical care.

VisitBrief

Staff preparing for a visit have to read several short documents and notice what is already recorded, what is missing, and what conflicts. VisitBrief keeps that judgment with the person. It is built for clinical staff, not for a patient looking for advice, and it prepares a draft from an allowlisted fictional chart. The staff member picks one of twenty built-in cases. There is no file upload and no free-form prompt, so the demo cannot accept a real patient record. One to three text PDFs are split into pages and source blocks. DeepSeek-V4-Flash on AMD Token Factory returns candidate facts. Radeon Cloud states that these catalog models run on AMD GPUs. The API keeps a fact only when its quote is inside the block it cites. If the model paraphrases a value, the screen shows the quote instead. Wording that is not in the assigned block is dropped and is not repeated. Duplicates are merged. A date that is not in the quote is cleared, so undated facts stay off the timeline. Two recorded doses of the same medicine are shown side by side and are not reconciled. A sentence that tells the model to ignore instructions or invent a diagnosis is dropped, and the case is flagged. Missing allergy documentation stays a review flag, not a finding of no allergies. The screen counts candidates that were kept, repaired, or dropped, and it labels the result as a draft for clinician review. There is no database. Request logs do not store document text. Held-out cases were not used to change the prompt. One pass on 15 October recalled 27 of 58 curated development facts (46.6 percent) and 34 of 43 held-out facts (79.1 percent).

First Commit

An Agentic AI that allows freshers in a company to understand the codebase clearly in their preferred way gives them a detailed overview of all the available Issues currently in the codebase, what actually needs to be fixed for each issue, and how a beginner might be able to tackle it. Issues dealing with multiple files, multiple cross-linked functions, and classes are marked as high blast radius, while issues that are relative to the local file itself are marked with a sub-zero blast radius. It not only shows you which issues are harder to tackle but also, guides one through the entire process of selecting and actually commiting code to the codebase without actually bringing production down. Every time a user commits code from our app, it goes through intensive checking and code testing to actually make sure production isn't hampered, making the lives of the senior engineers' lives a little easier. We further want to turn this into an IDE Plugin for VS Code or JetBrains-based IDEs so that the user can directly access it from their dev space

Patchcourt

## Problem & Solution Statement **The problem: AI auto-fix tools are untrustworthy because the model that writes a patch also grades its own homework.** When an LLM proposes a code fix, it has already reasoned its way to a conclusion. Its chain-of-thought is invested in the solution being correct. Asking the same model — with the same context, the same reasoning history — to then verify the fix is not verification. It is confirmation bias with an API. This is why engineering teams who pilot AI code review tools almost always add a rule: "someone still has to read every AI-authored change before it merges." The time savings disappear. This isn't a new problem. Security researchers solved the equivalent issue in human review decades ago: the person who writes the code cannot be the person who approves it. The same structural separation is what makes AI auto-fix trustworthy — and it is almost universally absent from the tools available today. Most competing approaches (single-pass LLM reviewers, "chat with your codebase" tools, inline copilot suggestions) are variations of the same self-grading loop. The fix gets proposed and accepted in the same context window. **PatchCourt breaks that loop at the architecture level.** The pipeline separates every job into an isolated Bob subagent with a scoped context: 1. **Two Auditor subagents** scan the repo in parallel — one for security weaknesses (eval injection, missing bounds checks, silent aliasing), one for test-coverage gaps — and return structured `Finding` objects. Neither auditor can write files; they can only read. 2. **A Fixer subagent** receives exactly one finding and produces a minimal patch (`diff` + private `rationale`). It writes only the specific file named in the finding — nothing else. 3. **A Verifier subagent** runs in a completely fresh context (`fork_context: false`, `subagent_type: explore`). It receives the finding and the diff. The rationale is stripped by the orchestrator before the Verifier is spawned — it is architecturally unreachable, not just omitted by convention. The Verifier reads the diff, reads the test output (before and after), and returns a structured `Verdict` with concrete evidence. It cannot write files. 4. Only patches with `verdict: "pass"` are accepted and bundled into a PR. Rejected patches are logged with the Verifier's reason. The rejection log is a first-class output — a Verifier catching a bad patch is the demonstration, not a failure mode. This run found 17 issues across three source files, patched three of them, and had all three independently verified as correct. Test results moved from 7/10 passing to 10/10 passing. Estimated manual review time for the same three findings: 45 minutes. Actual pipeline time: ~5 minutes. The architectural claim is simple and falsifiable: if the Verifier's context ever included the Fixer's rationale, the isolation collapses and the tool becomes another self-grading loop. The implementation enforces this at the API call level, not just in the prompt.

RealityCheck: Repair Workflows with IBM Bob

AI coding agents are increasingly capable of finding and fixing bugs, but a critical gap remains before those fixes can be trusted in release-sensitive workflows: how does a developer know that the repair was justified, the test defining success was not changed during repair, and the final result is reproducible? A green test suite alone does not answer those questions. An agent could misinterpret a requirement, weaken a test, accidentally change verification inputs, or report success after an incomplete execution. RealityCheck is a structured developer-verification workflow built around IBM Bob that turns contract mismatches into reviewable repair evidence. Developers begin with an application, documented requirements, source notes, and existing tests. RealityCheck guides Bob through a repeatable process: 1. Establish the application's existing baseline. 2. Use parallel read-only investigations to compare documented requirements with implementation assumptions. 3. Present a candidate finding, counterexample, and regression test for human acceptance. 4. Freeze the accepted contract, fixtures, tests, and verification tooling using cryptographic hashes. 5. Reproduce the failure against the original application before allowing repair. 6. Restrict the repair to the application boundary. 7. Re-run the unchanged accepted tests and original baseline through a deterministic runner. 8. Produce an evidence record containing the requirement, application snapshots, original failure, repair, verification results, and limitations. Our prototype demonstrates this on a retail-ingestion application. In the first scenario, all original tests passed, but Bob discovered that invoice identifiers were converted through integers despite a contract requiring exact string preservation. RealityCheck reproduced the leading-zero failure before permitting a one-line repair, then verified the unchanged regression test and baseline suite. The second scenario demonstrates interacting requirements around replay safety, identity conflicts, preservation of distinct records, and batch atomicity. Three behaviors initially failed while one preservation guard already passed. The accepted tests were frozen before Bob repaired the implementation, requiring one fix to satisfy all constraints simultaneously without changing the definition of success. RealityCheck is designed for developers, reviewers, and engineering teams using AI-assisted coding in maintenance, debugging, testing, and release workflows. Its key distinction is simple: Bob proposes and performs the repair. RealityCheck preserves the evidence that makes that repair reviewable. The final verdict is deliberately bounded to verified_for_tested_scenarios, not “bug-free” or “production-safe”, so the strength of the claim never exceeds the evidence collected.