How I built an AI workflow for my personal brand

I built a personal brand workflow because I don't think having a useful public voice should require taking on a second job.

Most professionals already encounter enough material to say something worthwhile. They read about their industry. They notice where a process breaks. They hear the same question from customers. They develop opinions through doing the work.

Very little of that becomes visible.

There is a gap between having something to say and getting it into a form you are willing to publish. Finding the article again, checking the details, shaping the thought, choosing an image, and remembering to post all take time. Each step is small. Together they are enough to make the whole thing inconsistent.

The workflow I built closes that gap. It brings my interests, relevant news, and the work I want to talk about into a simple approval interface. It prepares drafts in my voice, brings in suitable images, and handles the publishing cadence. I choose what represents me.

That choice is the center of the system.

My interests determine what comes in. My judgment determines what goes out. The machinery does the work in between.

I think this belongs in the tool belt of every salesperson and, increasingly, every professional who wants to work in an AI-native way. Being good at something and being legible to other people are separate problems. A career benefits when the second stops consuming so much of the time needed for the first.

A personal brand, as I think about it, is the accumulated evidence of how you see things.

It includes what you notice, what you find useful, what you disagree with, and what you leave alone. Someone who reads you over time should develop a reasonable expectation of the judgment they would get in a conversation or a working relationship.

That expectation cannot be produced by volume alone. You can publish constantly and still leave people with no idea who you are.

Choosing the inputs

So I built the workflow around selection.

The input side contains the topics I care about and the sources I want to follow. For me, that includes AI, philosophy, evidence, economics, science, technology, and how organizations work. Someone else might care about enterprise software, healthcare, architecture, logistics, or a particular market.

The point is that the interests belong to the person. The system works inside those interests rather than treating the entire internet as a pile of material that needs another caption.

Relevant articles enter as candidates. A candidate needs a reason to matter. It might change an assumption, introduce a useful capability, expose an incentive, or clarify a problem the audience actually faces.

The drafting stage asks what there is to say about it.

Repeating a headline rarely earns anyone's attention. A useful post makes a connection, offers an interpretation, or gives someone a practical move they can use. Sometimes the right response is simply to point at excellent work and let it stand. Sometimes an article deserves no post at all.

I want the system to be comfortable with both.

That requires separating relevance from publishability. Something can be relevant to my interests and still be wrong for my feed. An interesting article is an input. My endorsement is a decision.

The source stays attached to the draft so the factual basis can be checked. A source link and a published link serve different purposes. I need to know where a claim came from even when the post itself works better without a link.

Time matters too. A reaction to a recent development has a different shelf life from a useful observation about negotiation or decision-making.

Topical drafts carry an expiry. If the moment passes before I approve or publish them, they retire. The queue should not quietly turn last week's reaction into today's supposed insight just because it finally reached the front.

Fresh topical material can take priority over evergreen drafts while it is still relevant. Evergreen material provides continuity when there is nothing timely worth saying.

That combination gives the workflow room to be useful without chasing every news cycle.

A voice that survives the session

The next layer is voice.

“Write this in my voice” sounds simple until a system has to do it repeatedly. It can learn a few recognizable phrases and still miss the person. Worse, it can make every post sound like the same polished observation with different nouns.

I keep the voice instructions as a durable document. They cover interests, tone, spelling, recurring preferences, and the patterns I want the drafting process to avoid. A fresh drafting session reads them rather than trying to reconstruct my preferences from an old conversation.

The rules are specific because the failure modes are specific.

I want practical observations alongside philosophical ones. I want a real range of subjects. I don't want invented numbers, a company link stapled to every thought, or the same contrarian structure repeated all week.

A feed needs variation in stance as well as form. Some posts can be certain. Some can be puzzled. Some can admire something. Some can be brief and stop before they explain the entire world.

That variation matters because a person's voice contains moods. A system that turns every subject into a miniature lecture eventually sounds like a system.

The history matters as much as the instructions.

Previous posts show what has already been said. Declined drafts show what I don't want to say. Revision notes show where a thought was close enough to deserve another attempt.

Those are different signals. A rejected idea should not return a few days later in a new sentence. A request for a different angle should not produce the original argument with smoother wording.

I can add standing voice rules from the same interface where I review drafts. The correction becomes part of the brief for later writing. If I have already explained a preference, I should not need to explain it to the next session.

That is a modest but important form of learning. The system retains the correction in a place that subsequent work reads.

The approval interface

The interface is deliberately simple.

In my implementation, drafts arrive in a simple messaging interface. I see the proposed text and, when relevant, the image. I can approve it, skip it, or reply with a note.

Those three actions cover most of the editorial work.

Approve means this is something I am willing to put my name on. Skip means leave it out. A reply means the idea needs another pass.

The revision path is essential. A binary approval interface encourages people to accept something that is almost right because starting again feels expensive. Being able to say “keep the example, change the conclusion” or “this sounds too certain” makes the interaction much closer to editing with someone who knows the assignment.

The notes stay with the draft. The rewrite returns for approval. Asking for a change does not silently authorize publication of the revised version.

The ordering of those decisions also matters. If a note and an approval arrive together, the note takes precedence because there is something unresolved. An explicit decline takes precedence over both. An accidental double tap should never become a publishing decision.

The system sends a manageable batch rather than filling the chat with an entire backlog. I can make several decisions together and then leave the publishing schedule to do its job.

That changes the shape of the workday. I no longer need to encounter an idea, write a post, find an image, and publish it in one uninterrupted moment. The system assembles the decision so I can make it when I have attention available.

Images with a purpose

Images follow the same approach.

The workflow pulls relevant image candidates through source APIs and carries their source information with them. The image has to add something: a place, an object, or a scene that helps the reader understand the subject.

Most ideas do not need a decorative photograph.

The source rules are explicit, including which licensing categories are acceptable. A picture attached to a news article is not automatically a picture I can reuse. Image selection needs to preserve that distinction before the draft reaches me.

The preview is part of the approval. I can replace the proposed image by replying with one of my own, or remove it. The publishing path retains the image shown in the review interface so it does not depend entirely on the original URL still working later.

That is a small detail with a real effect on trust. Approving a draft should correspond to what the system is preparing to publish.

The implementation also has a defined fallback when an image cannot be uploaded: the approved text can go out on its own, with the failure reported. A missing photo should be handled according to a known rule, rather than leaving the entire queue silently stuck.

Cadence and reliable publishing

Once a draft is approved, timing becomes a separate responsibility.

Approval does not mean “publish everything now.” It creates a supply of material I have already chosen. The scheduler spreads that material across the configured cadence.

The queue exposes what is approved, what is waiting for a decision, what is being rewritten, and how much runway remains. I can preview the next post, inspect the schedule, or explicitly ask for the next approved item to go out now.

That gives me control without requiring me to manage a calendar entry for every post.

My own implementation uses publishing windows with a minute selected deterministically for each date and slot. The clock and publisher can calculate the same time independently. It varies the minute without requiring another agent to make a scheduling decision.

A scheduled serverless worker supplies the clock and wakes the hosted workflow. The source host's scheduled runs provide a backstop. The publishing process independently checks whether a slot is due and whether it has already been filled.

A wake-up is an invitation to check the queue. It is not permission to post again.

Missed slots are forfeited. If the system wakes up after an outage, it does not try to compensate by publishing a burst of old material. The cadence is there to support a useful presence, and the recovery behavior needs to preserve that purpose.

The queue has explicit states for new, sent, approved, revision, posting, and posted work. A draft has an identity across those transitions. The system can explain where it is instead of reducing every problem to “something didn't run.”

The implementation is intentionally small: a publishing and queue layer, a versioned voice file, a hosted workflow runner, a scheduling worker, an approval interface, and the professional network's publishing API.

The drafting intelligence sits upstream of the publication mechanism. Once a post is approved and due, publishing it should be a deterministic operation.

That separation is useful for another reason: public writes have awkward failure modes.

If a request to publish times out, the post may already exist. Repeating the request can put the same thing on the profile twice. The caller's uncertainty does not mean the platform refused the action.

The queue claims the draft before publishing. If the process is interrupted around the public write, the draft can remain visibly stranded for reconciliation. The system does not automatically treat an ambiguous attempt as permission to try again.

Warnings cover the failures that would otherwise be quiet: credentials approaching expiry, a queue running short, and a stranded draft holding up publication.

These are unglamorous details. They are also why a workflow can be trusted to operate while I am doing something else.

Connecting the company feed

The more interesting extension is the connection to work.

My professional identity includes the company I work with, but it is larger than that company. I want the workflow to handle both without flattening one into the other.

So company information joins as an additional feed.

That feed brings in material suitable for public discussion: product updates, published articles, announcements, useful customer problems, approved examples, and the work the company wants people to understand. It arrives in the same editorial process as my other interests.

I still choose whether to use it.

A new product capability might become a post about the problem it solves. A company article might be useful because it explains a pattern I see in the market. An announcement might matter to my audience, or it might belong on the company page and nowhere else.

The employee's perspective is what gives the material a reason to appear on a personal account.

For a salesperson, that connection is especially practical. The work already produces questions worth answering. What do prospects misunderstand? What causes a project to stall? What tradeoff keeps coming up? Which assumption makes someone buy the wrong thing?

A useful post can address one of those questions before the next sales conversation.

The company benefits because more people understand its work through someone they recognize. The individual benefits because their judgment becomes visible alongside their role.

I want that relationship to be voluntary and additive. The company feed supplies possibilities. It does not take over the person's publishing decisions or make every post sound like an announcement.

The cadence also needs an editorial balance. A week of company updates can crowd out everything that made the person worth following. The workflow keeps company material alongside personal interests so I can see that mix while choosing.

This makes the personal brand portable. A person can change jobs without replacing their interests, voice, or history. The company connection changes. The editorial identity remains theirs.

There is a broader implication here for how organizations communicate.

A company has people who understand different parts of its work: salespeople hear buying objections, engineers understand technical tradeoffs, operators see execution problems, and leaders make choices under uncertainty.

An approval workflow makes it easier for those perspectives to reach an audience. It reduces the production work required to express them while preserving the person's decision about what to say.

That can make an employee a useful marketing amplifier without turning them into a distribution endpoint for centrally written copy.

The distinction shows up in the result. A reader should encounter a person making sense of something relevant to their work. The company earns attention through the usefulness of that perspective.

I don't think the goal should be to make everyone publish more.

I think the goal should be to make worthwhile expression easier to sustain.

The workflow removes much of the recurring work of searching, preparing, formatting, selecting media, scheduling, and handling routine publication. What remains is the part that actually belongs to me: deciding whether a thought is mine, whether it is useful, and whether I want it in public.

That is still work. It is a much smaller and more valuable piece of work than rebuilding the entire publishing process every time.

A connected professional workflow

The same pattern appears in the other loops I have built.

In the development loop, a problem becomes a story, a bounded implementation, a review, and evidence. In the support loop, a customer report becomes a fix, a release, communication, and a retained outcome.

Here, an interest or source becomes a draft, an editorial decision, a scheduled publication, and a history that informs future drafting.

All three depend on separating preparation from authority. The system can prepare a great deal. The consequential decision still needs the right owner and a durable record.

They also improve through explicit feedback.

A correction to a draft can become a voice rule. A repeated operational failure can become a technical fix. A useful lesson from building software can become material I choose to write about. The systems create opportunities for each other without automatically turning every internal event into a public statement.

That is how the loops can connect without consuming my attention at every handoff.

There is a tempting way to use AI that simply adds another inbox: more suggestions, more drafts, more things to review. I want the workflow to earn its place by reducing the total burden. A revision should take priority over producing ten new options. An empty queue should be visible. An irrelevant story should be discarded before it asks for my time.

The interface should make choosing easy because the preparation was done carefully.

For a professional considering this kind of system, the useful starting point is a clear editorial brief: what you care about, who you want to be useful to, what sources you trust, and what you are willing to approve under your name.

The software can carry those choices forward. It cannot make them meaningful on your behalf.

My view is that this becomes a normal part of professional infrastructure. People already use systems to organize meetings, manage relationships, and keep track of work. A system that helps them express what they know belongs alongside those tools.

It lets a salesperson stay visible without becoming a full-time content producer. It lets a specialist share useful thinking without learning an entire publishing discipline. It gives an employee a straightforward way to contribute to their company's reach while retaining their own voice.

I built mine so the process fits around the work I already do. My interests supply the material. My experience supplies the judgment. The system makes the next decision easy and takes care of the follow-through.

I open the queue, choose what I want to say, and get back to work.