ChatGPT as a Platform: Tools, Agents, and Real Workflows

Most people use ChatGPT as a very good chat box. That is a legitimate use and it is roughly a tenth of what the product has become. Underneath the conversation there is now a platform — custom assistants, connected data sources, file analysis, scheduled work, image generation and agentic browsing — and the difference between using the chat box and using the platform is the difference between a helpful tool and something that removes recurring work from your week.

This guide covers what those capabilities actually are, which are worth the setup effort, how to build workflows that hold up when someone else uses them, and where the whole thing still disappoints. No code.

• The capability layers beyond ordinary chat
• Custom assistants: what they solve and what they do not
• Working with files, data and connected sources
• Agentic behaviour — browsing, multi-step tasks, scheduling
• Designing workflows that survive being handed to a colleague
• Governance, data handling and the limits worth knowing

1. The layers of the platform
2. Getting more from plain conversation
3. Custom instructions
4. Memory
5. Projects
6. Custom assistants
7. Knowledge files and their limits
8. Working with data and files
9. Connected sources
10. Browsing and research
11. Agentic tasks
12. Scheduled work
13. Voice and images
14. Designing a workflow that lasts
15. Team and organisational use
16. Data handling and governance
17. Where it still disappoints
18. Choosing between the app and the interface for developers
19. Twelve mistakes
20. A worked example: a weekly competitive brief
21. Frequently asked questions

1. The layers of the platform

The pattern worth noticing: the layers with the lowest setup effort have the highest return, and most people never configure them. Custom instructions take ten minutes once and improve every conversation afterwards.

2. Getting more from plain conversation

Before any configuration, most of the gap between mediocre and excellent output comes from how the request is made.

Supply the material. The single highest-leverage habit. A model working from a document you pasted is accurate; one working from memory is approximating. Almost every complaint about accuracy traces to asking for recall when the source could have been supplied.

Say who it is for and what it is for. "Summarise this for a board paper" and "summarise this for the engineering team" should produce different documents, and they will if you say which.

Show an example of the output shape. One example does more than a paragraph of description.

State constraints. Length, tone, what to omit, what must be included. Unstated constraints are unmet constraints.

Iterate on the prompt, not the output. Fixing an answer by hand produces one good answer. Fixing the prompt produces every future answer.

Ask for the reasoning on anything you need to check. A visible argument is verifiable in a way a conclusion is not.

3. Custom instructions

A persistent block of context applied to every conversation. Two parts: something about you, and something about how you want responses.

What genuinely helps in the first: your role and what your organisation does, your domain and its vocabulary, your technical level, and the tools and systems you work in. This context removes an enormous amount of hedging and irrelevant explanation.

What helps in the second: preferred length, whether you want caveats or directness, formatting preferences, and specific dislikes. If you never want a bulleted summary at the end of a prose answer, say so once.

Two cautions. Keep it short. A long instruction block competes with the actual request for attention. And revisit it occasionally, because an instruction written for one kind of work will quietly distort another.

4. Memory

The assistant retains facts across conversations — projects you are working on, preferences you have expressed, details about your context.

Useful for personal work, where not re-explaining your situation each time is a genuine saving. Less useful, and occasionally counterproductive, for varied work, because a fact learned in one context can surface unhelpfully in another.

The practical advice: review what has been stored periodically and remove what is stale. A remembered preference from a project that ended six months ago is now noise, and it is invisible unless you look. Turn memory off entirely for anything sensitive.

5. Projects

A container grouping related conversations with shared instructions and shared files. Underrated, and the right default for any ongoing piece of work.

What it solves: context that would otherwise be re-pasted into every conversation, and the scattering of related chats across a history you cannot search well.

How to use one well: put the durable context in the project instructions — what this work is, who it is for, what the constraints are — and put the reference material in the project files. Then each conversation is just the specific question, with everything else already in place.

The unexpected benefit is organisational rather than technical: a project keeps a piece of work's thinking in one place, and coming back after two weeks is far easier than reconstructing it from a chat list.

6. Custom assistants

A configured assistant with its own instructions, knowledge files and capabilities, shareable with others.

The distinction worth understanding: custom instructions configure you; a custom assistant configures a job. One is about your preferences across all work; the other is about how a specific recurring task should be done, by anyone.

Where they genuinely earn their keep:

• A recurring task with a defined process. Drafting a particular kind of document, reviewing something against criteria, converting between formats you use.
• Encoding organisational knowledge. Your tone of voice, your templates, your review criteria, your definitions.
• Anything you want colleagues to do consistently. The instructions do the standardising.

How to build one that works:

Narrow it aggressively. An assistant that does one thing well beats one that does six things adequately. The instructions become specific rather than general, and specificity is what produces quality.

Write instructions as a process, not a description. "Ask for the audience first, then produce three options at different lengths, then wait for a choice before elaborating" is executable. "Be a helpful writing assistant" is not.

Define the output format precisely, with an example.

Say what to do when information is missing. The default is to guess. Instructing it to ask instead is usually better and is the difference between a usable assistant and one that confidently produces the wrong thing.

Test with the awkward cases, not the obvious ones. Give it an ambiguous request, an incomplete one, and one just outside its remit.

7. Knowledge files and their limits

Files attached to an assistant that it can draw on. Straightforward in principle and with limits worth understanding.

Retrieval finds passages matching your query rather than reading the whole corpus. This means it works well for factual lookup — what does our policy say about X — and poorly for questions requiring the whole document, like "summarise the themes across these fifty reports". The retrieval finds a few relevant chunks; it does not synthesise across everything.

What makes retrieval work better: well-structured documents with real headings, because chunking follows structure; fewer, better-organised files rather than everything you have; and removing outdated material, since retrieval cannot tell which of two contradictory documents is current.

That last point causes the most trouble in practice. An assistant with the 2023 and 2025 versions of a policy will confidently cite whichever chunk matched better.

8. Working with data and files

The ability to analyse uploaded files — spreadsheets, documents, images, data exports — is among the most immediately useful capabilities and among the least used.

What it handles well: exploring an unfamiliar dataset, cleaning and reshaping, statistical summaries, charts, cross-referencing files, and extracting structure from documents.

What to be careful about:

Verify the numbers. The analysis is generally sound and occasionally makes a subtle error in interpreting a column or handling missing values. Spot-check anything consequential against a figure you can compute independently.

State the meaning of your columns. A column called "value" could be anything, and it will be interpreted plausibly rather than correctly.

Ask what it did. Requesting the steps it took is how you catch a wrong assumption about your data — and it is far faster than checking the output.

Mind the size. Very large files hit limits. Sampling or aggregating first is often the answer.

9. Connected sources

Connections to your own systems — document stores, email, calendars, code repositories, internal tools — so the assistant can answer using live data.

The value is obvious: answers grounded in your actual information rather than what you remembered to paste.

The considerations are the ones any integration raises. Permissions should mirror the user's own — a connection where everyone effectively shares one account's access is a permission-bypass tool. Content retrieved is untrusted input, which matters when a document could contain text crafted to look like an instruction. And read-only connections are dramatically safer than ones that can act, because the worst outcome of a bad retrieval is a wrong answer rather than a sent message.

The practical advice: connect the read-only sources that answer real questions, be deliberate about anything that can act, and check what a connection actually exposes before enabling it for a team.

10. Browsing and research

The assistant can search and read current sources, which addresses the training-cutoff problem directly.

Where it is strong: current information, comparing several sources, finding recent developments, and checking a claim.

Where to be careful: it can be misled by confident sources, and it does not weigh credibility the way a researcher does. Ask for the sources and check the ones that matter — a citation you did not open is a citation you are trusting blindly. And for anything where the answer changes over time, note that the search results are today's, which matters if you are producing something durable.

The most useful pattern is asking for a comparison across sources with disagreements flagged, rather than a single synthesised answer. Disagreement between sources is information, and a smoothed summary hides it.

11. Agentic tasks

Beyond single answers, the assistant can work through multi-step tasks — searching, reading, comparing, compiling — with the steps chosen as it goes rather than specified in advance.

This works well for: research requiring several sources, comparisons across options, gathering information scattered across places, and any task where the next step depends on what the last one found.

It works less well for: anything requiring judgement about what matters, tasks with implicit standards nobody stated, and work where being subtly wrong is expensive.

How to get good results:

Be explicit about the output you want, including its structure. An open-ended research task produces an open-ended document.

Say what sources to prefer or avoid.

Ask for the working — what it looked at and what it found — so the conclusions are checkable.

Give it a scope. "The top five by market share" is bounded; "the main players" is not, and unbounded tasks produce unpredictable effort.

12. Scheduled work

Tasks that run on a schedule and deliver results without you initiating them — a morning brief, a weekly summary, a monitor for something changing.

This is the capability with the largest gap between how useful it is and how many people use it, and the reason is that it requires thinking about a recurring need rather than an immediate one.

What works well as a scheduled task: a digest of developments in a specific area; a weekly summary of something you track; a check for a specific change; a recurring draft you always edit anyway.

What to watch: a scheduled task you stop reading is worse than no task, because it accumulates. Review after a month and delete what you skip. And make the output specific enough to be actionable — a general summary of an industry is interesting once and ignored thereafter, while a specific question answered weekly stays useful.

13. Voice and images

Voice changes what the tool is good for more than it changes what it can do. Talking while walking, thinking aloud, working through a problem conversationally — these are genuinely different modes of use rather than the same use with a different input. It is also markedly better for exploratory thinking and worse for anything needing precision.

Image understanding is more useful than most people realise. A photograph of a whiteboard, a screenshot of an error, a chart from a report, a diagram you need explained — all workable inputs. This is frequently faster than describing something in words.

Image generation is best treated as a drafting tool: concepts, mock-ups, illustrations for internal use. Anything requiring precise text, exact brand assets or fine control will need a designer, and expecting otherwise wastes time.

14. Designing a workflow that lasts

Most people build something useful once and never make it reusable. The step from a good conversation to a durable workflow is small and rarely taken.

1. Notice the repetition. Anything you have done three times is a candidate.
2. Capture the prompt that worked, not just the output.
3. Generalise it — replace the specifics with placeholders.
4. Decide where it lives. A project for your own ongoing work, a custom assistant for something recurring or shared.
5. Add the context it needs as instructions and files rather than pasting it each time.
6. Test it on a case you did not design it for. This is where the gaps show.
7. Write down what it is for so a colleague can tell whether to use it.
8. Revisit quarterly. Workflows drift out of date, and an assistant referencing last year's process is worse than none.

15. Team and organisational use

Shared use raises questions individual use does not.

Shared assistants standardise work, which is their main organisational value. A review assistant encoding your actual criteria produces more consistent reviews than a policy document nobody reads.

Ownership matters. An assistant nobody maintains becomes wrong and stays in use. Name an owner or expect drift.

Discoverability is the practical bottleneck. Organisations accumulate dozens of assistants nobody can find, and people rebuild what already exists. A simple index with what each one is for solves most of it.

Set expectations about verification. The failure mode in team use is someone treating output as authoritative because it came from an official assistant. Say explicitly what needs checking.

16. Data handling and governance

The questions to answer before organisational rollout, in the order they matter:

Is our data used for training? Business and enterprise plans generally exclude it; consumer plans may not by default. Check rather than assume, and check the current terms rather than what you remember.

What is retained, and for how long? Conversations, uploaded files, and connected data all have retention policies, and they differ.

Who can see shared assistants and their knowledge files? An assistant with a confidential document attached is a distribution mechanism for that document.

What do connections expose? A connection inherits access, and the question is whose.

What is the acceptable use policy? People need to know what may be pasted in. A clear, short policy that names specific categories works; a vague one gets ignored.

The most common governance failure is not a technical one. It is having no policy, so everyone decides individually, and someone eventually pastes something they should not have.

17. Where it still disappoints

Honestly, because knowing the limits saves more time than knowing the features.

Long documents produced in one pass drift — losing consistency, repeating themselves, contradicting earlier sections. Better produced in parts.

Specific factual details — figures, dates, citations, identifiers — remain the weak point unless grounded in supplied material or retrieved. Verify these specifically rather than reviewing generally.

Genuinely novel problems get plausible, confident, sometimes wrong answers. The tool is strongest where similar problems exist in what it learned from.

Anything requiring your organisation's unwritten context — why a decision was made, what a stakeholder actually cares about — is invisible to it.

Precision formatting. Complex documents, exact layouts, and anything where the format is the deliverable will need hand-finishing.

Consistency across separate conversations. The same request in two chats produces two answers. Where consistency matters, that is what an assistant with fixed instructions is for.

18. Choosing between the app and the interface for developers

A recurring question worth a straight answer.

The application is right when a person is in the loop, when the work is exploratory, when you want capabilities — files, browsing, connections — without building them, and when the users are not developers.

The developer interface is right when the work must run without a person, when it is embedded in a product, when you need control over models and parameters, when volume makes per-seat pricing wrong, or when the output feeds another system.

The practical route most teams take: prototype in the application until the prompt and the process are proven, then rebuild in code once the workflow is stable and needs to run automatically. Doing it in that order saves a great deal of building the wrong thing.

19. Twelve mistakes

1. Never setting custom instructions. Ten minutes that improves everything afterwards.
2. Relying on recall instead of supplying material. The root of most accuracy complaints.
3. Building assistants that do six things. Narrow ones are better at all six.
4. Instructions that describe rather than instruct. Write the process.
5. Contradictory knowledge files. Retrieval cannot tell which version is current.
6. Trusting analysis without spot-checking. Subtle column misinterpretation is invisible.
7. Not opening cited sources. A citation you did not check is a trusted guess.
8. Scheduled tasks nobody reads. Worse than none.
9. Assistants with no owner. They drift and stay in use.
10. No index of shared assistants. People rebuild what exists.
11. Confidential material in shared knowledge files. A distribution mechanism you did not intend.
12. No usage policy. Everyone decides individually, and eventually someone decides wrong.

20. A worked example: a weekly competitive brief

A product manager wants a weekly summary of what four named competitors have shipped, announced or been written about — currently assembled by hand in about ninety minutes every Monday.

First attempt: a good conversation. A detailed prompt naming the four companies, asking for product announcements, pricing changes and notable coverage from the past week, with sources. The result is genuinely useful and takes four minutes instead of ninety. It is also a one-off, and next Monday means retyping the prompt and remembering what was included.

Second step: making it durable. The prompt is generalised — the date range becomes "the past seven days" — and moved into a custom assistant. The assistant's instructions specify the four companies, the three categories to cover, the output structure, and explicitly what to exclude: funding rumours, recycled press releases, and anything more than a week old. That exclusion list is what stopped the brief filling with noise.

Adding context. Two files are attached: a one-page description of the product and its positioning, and the previous eight weeks of briefs. The first lets the assistant judge relevance rather than listing everything. The second lets it flag what is new against what has already been reported, which turned out to be the single most valuable addition — the manual process had been repeating items week to week without anyone noticing.

Instructions written as a process. Search each competitor separately rather than in one query, because a combined search returns whichever company generated the most coverage. Check the previous briefs before including anything. Structure the output as one section per competitor with a maximum of four items each. Flag anything that appears to be a material strategic shift separately at the top. And where nothing significant happened for a competitor, say so in one line rather than padding.

Scheduling it. Set to run Monday mornings, delivering the brief before the person starts work. This is the step that changed it from a tool they use to a thing that arrives.

What went wrong in the first month. Two things. The assistant initially treated every product blog post as an announcement, so the brief was long and low-signal; adding an explicit relevance test — does this change what a customer can do, or what they pay — cut the volume by half and improved it. And it twice cited a source that had reported a rumour as fact, which is the characteristic browsing failure; the fix was instructing it to mark single-sourced claims explicitly rather than to avoid them, since a single-sourced claim is still worth knowing about if labelled.

What it is still not. The brief does not know which of these developments matter to this business, because that judgement depends on strategy discussions that exist nowhere it can read. It reliably assembles and filters; the interpretation is still the person's job, and the ninety minutes saved went into that rather than disappearing.

21. Frequently asked questions

What is the single highest-return thing to set up?

Custom instructions. Ten minutes describing your role, your domain and how you want responses, applied to every conversation afterwards. Most people never do it and then wonder why the answers feel generic.

When should I build a custom assistant rather than just prompting well?

When you have done the same task three times, or when someone else should be able to do it the same way. A good prompt used once is a conversation; a good prompt used weekly by four people should be an assistant with the context and process built in.

Why does my assistant ignore its knowledge files sometimes?

Retrieval matches passages against your query rather than reading everything, so a question phrased differently from the document's language may not match. Well-structured files with real headings help, as does removing outdated versions — retrieval cannot tell which of two contradictory documents is current and will cite whichever matched better.

Can I trust the data analysis?

Generally sound, and occasionally subtly wrong about what a column means or how missing values should be treated. Ask it to state the steps it took, which surfaces a wrong assumption faster than checking the output, and independently verify one figure you can compute yourself before relying on the rest.

Is our data used for training?

Depends on the plan, and it is worth checking the current terms rather than assuming. Business and enterprise tiers generally exclude it; consumer tiers may not by default. This is the first question to answer before any organisational rollout, along with what is retained and for how long.

Should we connect it to our internal systems?

Read-only connections to sources that answer real questions, yes — grounded answers are substantially better than remembered ones. Be considerably more deliberate about connections that can act, ensure permissions mirror each user's own rather than sharing one account's access, and remember that retrieved content is untrusted input.

When should we move to building with the developer interface instead?

When the work must run without a person, when it is embedded in a product, when the output feeds another system, or when volume makes per-seat pricing the wrong shape. Prototype in the application first — proving the prompt and the process there is much faster than building it in code and discovering the approach was wrong.

How do we stop shared assistants going stale?

Give each one a named owner and review them quarterly. An assistant encoding last year's process is worse than no assistant, because people follow it. Also maintain a simple index of what exists and what each is for, or your organisation will accumulate dozens nobody can find and rebuild the same ones repeatedly.

Key takeaways

• The low-effort layers have the highest return. Custom instructions and projects, before anything elaborate.
• Supply the material. Grounded answers beat remembered ones, every time.
• Narrow assistants beat broad ones, and instructions should read as a process rather than a description.
• Scheduled tasks are the most underused capability — and the fastest to become noise if unread.
• Verify specifics: figures, dates, citations and identifiers are where errors hide.
• Prototype in the app, rebuild in code once the workflow is proven and needs to run itself.

The gap between casual and serious use of this platform is not about knowing clever prompts. It is about noticing which work repeats, capturing the version that worked, and putting it somewhere it will run again — which is ordinary process thinking applied to a new kind of tool.