DEV Community: Keith Azodeh

What to Record Before a Remote Publishing Job Starts

Keith Azodeh — Thu, 15 Oct 2026 23:05:24 +0000

A remote machine finishes uploading a video, then loses its connection before reporting the result. The dashboard still shows an unfinished task. Starting the worker again might recover the workflow. It might also publish the same video twice. The missing information is what happened between the command leaving the dashboard and the result reaching the operator.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

My Cloud Media Distribution case study describes a historical system built in 2024: a Flask control panel, an S3 media library, and Windows EC2 workers coordinated through AWS Systems Manager. Remote commands updated local controls and launched scripts that operated platform sessions. The project connected those components; it did not establish a measured publication success rate or an immutable job queue.

The opening scenario is hypothetical. It is a useful way to think through a redesign: what would the next operator need to decide whether to retry, investigate, or leave the job alone?

Give the intended work a stable identity

For a comparable system today, I would create a durable job record before dispatch. Give the intended publication its own identifier, then record each execution attempt separately. A retry belongs to the existing job; it should not silently create a new intended publication.

The record needs enough information to identify the work: destination account, media version, caption version, requested timing, and relevant configuration. A path named “current-video” is convenient for an interface, but it is a poor explanation of what an earlier attempt was supposed to publish if that path now points somewhere else.

Changing the approved caption or asset should create a deliberate revision. Reusing the same identity for different payloads makes later reconciliation harder. An operator looking at two attempts needs to know whether they attempted the same work.

That does not require a complex scheduling product on day one. Start with a record you can query after a process crashes. It becomes the place to attach dispatch history, observations, and the eventual result.

Preserve what a retry will execute

GitHub's October 14, 2026 workflow-lockfile public preview addresses a related problem in CI. A tag or branch referenced by a workflow can move after review. Lockfiles allow an onboarded workflow to execute recorded dependency commits while retaining those references in its configuration. GitHub also notes that locking a dependency does not establish that it is safe.

This is not a feature of my historical publishing system. The connection is an engineering principle: preserve the version you intended to execute. In a remote-worker redesign, I would record the worker release alongside the media and configuration versions. Otherwise, a later retry can differ from the original attempt even when its visible request looks unchanged.

There is a maintenance cost. Pinned versions need intentional updates, and old workers eventually need replacing. The benefit is that “retry this job” has a more precise meaning, and an operator can distinguish a content change from a software change.

Separate dispatch, execution, and publication evidence

The historical case study makes an important distinction: Systems Manager command success meant the remote command ran, not that a social post was independently verified. Its stop mechanism was also cooperative, checked at an iteration boundary rather than guaranteeing cancellation of an upload already underway.

For a redesign, I would retain those distinctions in the job's history. Record when dispatch was accepted, which worker started the attempt, what the worker observed, and what evidence supports completion. A platform-issued post identifier or a verified destination URL is different from a script reaching its last line.

An uncertain result deserves an explicit state. Before another publication attempt, reconcile against the destination through a supported interface where possible. If that check cannot establish what happened, route the job for review instead of translating a timeout into permission to publish again.

The same applies to stopping. A stop request, a worker acknowledging that request, and confirmation that no further publication will start are separate observations. Keeping them separate helps an operator understand what remains in flight.

Conditional storage writes solve a narrower problem

AWS's June 17, 2025 discussion of multi-writer S3 applications illustrates using conditional writes for object creation and shared metadata updates. This is established storage guidance, not an October release.

The S3 conditional-write reference describes If-None-Match for preventing an overwrite of an existing key, and If-Match for updating only when the supplied ETag matches. Those controls can help protect a shared record from a competing or stale writer.

They do not make an external publishing action and a storage update one transaction. A worker can still publish and then fail before saving the receipt. Protecting a job record is useful; it does not establish exactly-once publication across independent systems. Destination-side idempotency, when available, and reconciliation still matter.

For a small operations team, the practical consequence is a more useful dashboard. Show unresolved outcomes, the age of the last worker observation, and which version each attempt used. A green machine-status indicator alone cannot answer whether the intended work reached its destination.

Adding workers can increase the amount of work in flight. A durable job history improves the team's ability to explain and recover that work. Before expanding a remote automation system, make one interrupted attempt understandable to the person who has to pick it up.

Fast AI Prototypes Need Two Questions: Strategy and Optimization

Keith Azodeh — Thu, 15 Oct 2026 19:20:32 +0000

AI changes how quickly a small team can put an idea in front of someone. A pair of builders can sometimes produce a bounded prototype in days that would once have waited through weeks of departmental handoffs. That is an opportunity to shorten the distance to useful feedback. It is not a universal productivity benchmark or a promise about production readiness.

Disclosure: An AI agent drafted this article from my direction, personal background, public project documentation, and the linked technical sources.

In my consulting conversations with small-business owners and executives at large technology companies, I keep returning to two questions. Strategy: are we building the right thing? Optimization: can we make it work better with the time, money, and infrastructure available? A team can write code very quickly while leaving both questions unanswered.

Strategy decides which uncertainty to resolve

My public projects include supplier-price workflows, a voice operations product, a community guide, application tools, church operations, healthcare software, and forecasting research. They are not interchangeable success stories. Some are delivered work; others are ongoing products, staged migrations, or research prototypes.

Across professional projects and conversations spanning technology, real estate, insurance, healthcare, education, finance, and crypto, the domain changes what counts as a useful result. My experience across those settings is why I start with the workflow and the person using it. A faster interface does little if it accelerates the wrong decision.

For a first version, I would write down a person, a recurring task, and an observable improvement. “Help staff review an incoming record” is something you can test. “Transform the entire business with AI” leaves the team guessing what to build and the reviewer guessing what success means.

Then choose an experiment that could change your mind. If the real difficulty is inconsistent source information, an attractive dashboard will not settle it. If the difficulty is that nobody knows who should act next, another generated summary may add to the queue.

This is where making mistakes early is productive. An inexpensive prototype can reveal that a proposed workflow is confusing or that a feature is unnecessary. Retain the observation, revise the assumption, and try again before expanding the implementation.

Optimization follows evidence

Once a useful path exists, optimization becomes concrete. You can inspect repeated work, slow integrations, unnecessary model calls, oversized context, and the steps that still require someone to intervene. Pick the constraint that affects the outcome rather than optimizing whichever metric is easiest to display.

In TMC Price Intelligence, the documented work connects supplier emails and attachments to structured pricing and subsequent quote and invoice workflows. In SmartVoiceX, calling connects to scheduling, follow-up, and human handoff. The relevant unit of improvement is the useful workflow, not just an isolated model response.

For a new pricing tool, I would first check whether two offers are comparable. Only then would I spend time reducing the model work needed to process the next batch. Making an unreliable comparison cheaper does not make it useful.

Anthropic's December 19, 2024 guidance on effective agents recommends beginning with simple solutions and increasing complexity when warranted. It also recognizes the cost and latency tradeoffs of agentic systems. That older architectural advice remains relevant to a current temptation: adding another agent or reasoning step before identifying the problem it solves.

Leave room for discovery, and keep the lesson

A rigid demand for a perfect first attempt can encourage long instructions built around imagined failures. Unbounded retries create a different expense. I prefer a bounded experiment with a clear question, a reviewable result, and a decision about the next attempt.

When an experiment fails, record what it taught you. A confusing screen might lead to a changed interaction. A recurring extraction error might become an example or a test. An unnecessary generation step might disappear entirely. Fewer repeated investigations and smaller, relevant inputs can reduce token use, but the saving needs to be measured across the completed workflow.

That kind of improvement combines technical and creative work. Technical judgment helps you understand the constraints and verify behavior. Creative judgment helps you question whether the current design is the best way to meet the need. Speed becomes useful when it gives both kinds of judgment more opportunities to act.

Ownership is part of the product

My aim is to help people build their product and understand how to own it. Continued support can be a deliberate choice after handoff. It should not be necessary because the owner cannot find the source, understand the configuration, or make a routine change.

For a handoff, I would expect the owner to be able to locate the code and deployment process, understand recurring costs, change a key configuration, inspect a failed run, and recover a previous version. Growth then has a practical meaning: someone knows which parts must change when usage, data, or team size increases. A generated codebase alone does not establish that an implementation will scale.

Teaching is part of how I approach that problem. My seminars and events create space to discuss practical workflows. At AFROTECH, Building AfroTech.guide will use a specific build to explain the process and give attendees steps for starting their own AI-powered project.

Small teams now have more opportunities to test an idea before committing to a large build. Use that opportunity to resolve the strategy question, improve the working path, and transfer the knowledge. The owner should finish with a product they can operate and a better understanding of how to improve it.

Give Your AI Workflow Room to Make Useful Mistakes

Keith Azodeh — Thu, 15 Oct 2026 19:18:29 +0000

“Make no mistakes” sounds like a serious instruction. As a development process, it leaves out the most useful part: what happens when an assumption turns out to be wrong. A working prototype can expose that assumption in minutes. A longer prompt demanding perfection can keep it hidden behind a more confident answer.

Disclosure: An AI agent drafted this article from my direction, personal background, public project documentation, and the linked technical sources.

I started building AI-powered tools in 2019, before ChatGPT's public launch. The habit I want to carry into today's tools is simple: try something concrete, inspect what happened, and let the next attempt benefit from the mistake. Humans improve that way. An AI workflow needs a deliberate mechanism for carrying the lesson forward.

Give the experiment a question

There is a difference between asking for “a complete, flawless application” and asking whether a person can find one useful record and understand it. The second request creates something you can evaluate. It also leaves room to discover that the search box, the record structure, or your original idea needs to change.

My project archive spans application tools, voice workflows, supplier pricing, archive retrieval, community platforms, and computer-vision experiments. These are different kinds of work, with different maturity levels. I do not expect one enormous instruction to settle all their product and engineering questions in advance.

For a new idea, I would start with one uncertainty: Can the input be interpreted? Can the proposed interaction be understood? Can the output survive the next step? Then build the smallest attempt that produces evidence about it. A result that disproves the idea can be valuable if it prevents a week of polishing the wrong thing.

Make the mistake cheap to recover from

Room to experiment works best when the attempt has a boundary. Use a branch, a recoverable draft, sample records, or a practice environment. Set a concrete check before the experiment begins. A failed layout in a preview is a different situation from silently publishing that layout to customers.

Okeike's public case study describes recoverable drafts, inspectable AI-proposed edits, and publishing through versioned source control. Exempliph.ai's case study describes a practice workspace and a distinction between prepared applications and confirmed submissions. Those are documented design choices, not evidence that either product makes mistakes impossible.

For a comparable editing experiment, I would ask for a few navigation alternatives in a draft, try them against an actual page, and keep the one that makes the next action clearer. The discovery work can be flexible while publication remains a separate decision.

That balance gives creativity somewhere to operate. The model can suggest an unexpected structure without also receiving permission to overwrite every page. You can explore widely without making every experiment expensive to undo.

Turn the failed attempt into a reusable lesson

“It did not work” is too vague to improve the next run. Keep the input that exposed the issue, the expected behavior, the observed result, and the change that fixed it. When appropriate, turn that example into a regression check.

For example, a form mapper might confuse an employer's name with a job title. The useful correction is a specific mapping example and a check that preserves an existing answer. Adding “never misunderstand any form” to the prompt does not capture the distinction the failure revealed.

This is also where the human analogy has a limit. An ordinary inference session does not automatically retrain a model when you correct it. The workflow learns operationally when you retain the evidence in examples, tests, instructions, or retrievable notes. If the next run never receives that lesson, you may pay to rediscover it.

Anthropic's September 29, 2025 context-engineering article recommends starting with a minimal useful prompt, adding guidance from observed failures, and keeping context informative. It also describes persistent notes for long tasks. This is established engineering guidance, not a new October release.

Measure the whole attempt, not the length of the prompt

Allowing iteration can reduce token use when it replaces repeated broad rewrites, bloated instructions, or the same investigation performed again. It can also increase token use if the agent wanders, repeats failures, or generates ten alternatives when one would answer the question. Exploration is not a guaranteed discount.

Compare completed outcomes. Record model usage across the initial attempt, inspection, repairs, and final verification. Keep an eye on the human review time too. A short prompt with endless retries can be worse than a longer prompt containing the right example.

My preferred next instruction is specific: keep the working parts, change the failed behavior, and explain which evidence shows the correction worked. Once an approach is understood, ordinary code or a focused check may handle it more economically than asking a model to reconsider it every time.

I bring this attitude into the seminars and practical sessions I host. At AFROTECH 2026, my Building AfroTech.guide session will walk through a particular project and offer practical steps people can use in their own builds. The point is to make the process understandable, including the decisions that need another attempt.

A useful mistake changes the next experiment. Give the system a clear question, a recoverable place to try, and a way to retain the result. That creates more room for original ideas while keeping progress grounded in something you can inspect.

When a Caller Interrupts, Update the Voice Agent's Memory

Keith Azodeh — Thu, 15 Oct 2026 18:01:41 +0000

Imagine an appointment assistant offering two times: “I can offer Tuesday at ten, or Thursday at two.” The caller cuts in after “Tuesday at ten” to ask about parking. If the model later asks “Which of those two times works?”, it is relying on an option the caller never received. The audio stopped correctly. The conversation state did not catch up.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

My SmartVoiceX case study documents a built phone operations product with ongoing development: calling flows, calendar and API integrations, human transfer, and call records. Those features make conversation state consequential. A booking flow needs to know more than what the assistant intended to say.

The example above is hypothetical. The implementation pattern below is a proposed approach, not a claim that SmartVoiceX uses Twilio ConversationRelay or already implements these exact mechanisms.

Generated text is not a delivery receipt

Twilio's September 25, 2026 interruption-handling guidance describes a useful division of responsibility. ConversationRelay handles speech playback and interruption detection. The application still owns the model's conversation history. Twilio specifically advises updating that history to reflect the speech played before an interruption.

This is an ongoing voice-agent engineering concern, rather than a newly launched October feature. It matters as teams connect streamed speech to actual workflows: a model can finish generating a sentence well before playback finishes delivering it.

For the appointment example, I would keep distinct records of the complete generated response and the portion reported as played. The former is useful for debugging. The latter should shape the next conversational turn. Neither proves that the caller understood or accepted an offer.

That distinction changes the recovery response. The assistant can answer the parking question, then introduce the remaining option. It should not assume that two choices are already part of the shared conversation.

Use the interruption event without overreading it

The ConversationRelay WebSocket reference documents an interrupt message with utteranceUntilInterrupt and durationUntilInterruptMs. The first reports the utterance played before the cutoff; the second provides the elapsed duration. These are useful application inputs, not evidence of comprehension or confirmation.

In a comparable integration, I would reconcile the interrupted assistant turn before requesting the next model response. I would retain the generated text in an audit record, mark that turn as interrupted, and give the model the reported spoken portion with its interruption context. Simply deleting the entire turn could also lose something the caller actually received.

I would also stop forwarding obsolete output from that response. Cancellation alone needs scrutiny: an already scheduled callback may still deliver tokens. An application-owned response identifier can help reject output belonging to a superseded response. This is a proposed concurrency safeguard, not a field promised by Twilio's interrupt message.

The important invariant is practical: once a response has been superseded, its remaining speech should not reappear after the caller's new request. Test that property at the boundary where text leaves the application, including delayed output.

Keep calendar state separate from spoken state

Interrupting a sentence does not undo an external operation.

Suppose a calendar write succeeds, but the caller interrupts the confirmation. The application now has two facts: the appointment exists, and the confirmation was only partly delivered. Trimming the assistant's words must not erase the successful write or trigger a second booking when the conversation resumes.

For that situation, I would have the next response consult the recorded operation result and clarify the existing appointment. If the caller wants a different time, that is a new workflow decision. If the write is still pending, the application should preserve that uncertainty instead of improvising a result from the assistant's wording.

My Twilio field notes describe telephony as an integration boundary while the application owns business state and outcomes. Interruption handling is a specific reason to maintain that separation. Spoken text can describe an operation, but it is not the operation's source of truth.

Tune turn-taking around the kind of interruption

There is another distinction before history reconciliation even begins: did the caller intend to take a turn?

Twilio's September guidance separates deliberate barge-in, brief acknowledgments such as “uh-huh,” and background noise. Its discussion of sensitivity and backchannel controls illustrates why a single “stop when sound appears” rule can produce an awkward agent. But suppressing too much can make it difficult for someone to correct a mistaken date or stop an unwanted explanation.

For a booking assistant, I would test an explicit correction, a brief acknowledgment during an explanation, and a caller beginning a new question. Those scenarios need different observations. Count whether the agent yielded when appropriate, whether it resumed with an accurate history, and whether the underlying booking remained correct. Fewer interruptions alone would be a misleading success measure.

This affects how teams evaluate voice products. A smooth greeting and low response latency leave important behavior untested. The caller can change direction halfway through a sentence, while generation, playback, and an API operation are each at different stages.

A useful call record should let an operator reconstruct those stages without guessing which words reached playback or which action completed. That is where interruption handling becomes an operational feature: the next response, and the person reviewing the call afterward, need a truthful account of what has happened so far.

A Good Depth Map Can Still Make Bad Stereo Video

Keith Azodeh — Thu, 15 Oct 2026 13:05:35 +0000

Pause a depth-based stereo video and the foreground may look convincing. Press play and the same object can seem to breathe, its outline wobbling as it moves. A frame-by-frame comparison can miss the defect that dominates the viewing experience: the geometry will not stay put.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

My Stereo Depth Lab case study describes a working local prototype for turning images and short clips into stereo pairs. It uses relative depth, with Depth Anything V2 Small as the default estimator. Its lightweight Gaussian rendering path carries depth-seeded points across frames with optical flow, confidence, decay, and resets at scene cuts. That is an experiment in continuity, not a calibrated, trained 4D Gaussian reconstruction.

The implementation question is useful beyond this prototype: what should a developer test when the product is a sequence, but the easiest result to inspect is a single image?

Separate depth estimation from temporal behavior

Video Depth Anything, originally submitted on January 21, 2025 and revised on October 14, 2026, addresses this distinction directly. The authors build on Depth Anything V2 with a spatial-temporal head, a temporal consistency loss, and a strategy for long videos. Yesterday's revision date does not make the underlying method a new October launch. It is a current reference for an ongoing engineering problem.

The important architectural point is that temporal behavior is part of the model and inference design. Running an image estimator repeatedly does not, by itself, give that estimator a representation of what persisted between frames. The paper's approach and a lightweight renderer that reuses points operate at different parts of the pipeline. I have not established that swapping in the former would improve my prototype.

Consider a chair in a short clip. Its depth estimate can be plausible in each frame while its apparent separation from the wall varies. In a stereo conversion, that variation can become unwanted motion. A test needs to follow the chair through time, rather than approve several attractive stills.

Carrying state creates a second failure mode

Keeping information from previous frames can suppress instability. It also gives a mistake somewhere to survive.

Imagine a person walking behind a doorframe. A persistent point may help retain a stable surface until the person disappears. Once the surface is occluded, carrying that point forward without a reliable correspondence can produce a trail. Strong smoothing can also make a moving boundary lag behind the source footage.

Those are illustrative failure cases to test, not measured results from Stereo Depth Lab. The public case study documents the prototype's confidence, decay, and scene-cut reset mechanisms; it does not provide benchmark evidence that they resolve every case.

For an implementation review, I would ask how state enters, how it loses confidence, and when it is discarded. A hard cut is a particularly clear boundary: correspondence with the preceding shot should not be assumed. Gradual camera motion is harder because some surfaces persist, some leave the view, and others become visible for the first time.

This is why a single smoothing slider cannot explain every artifact. An unstable estimate, an incorrect motion correspondence, and an overlong state lifetime can all produce different kinds of trouble in the same clip.

Build a small test reel before choosing a larger model

For the next comparison, I would use a fixed set of clips with distinct failure opportunities:

A stationary scene, to expose unwanted changes without much real motion.
A slow camera pan past a nearby object, to expose newly visible background and edge behavior.
A moving subject crossing another object, to inspect occlusion and trailing state.
A hard cut between unrelated shots, to check reset behavior.

Keep the source clips and rendering settings fixed between runs. Save the model version, input size, eye separation, convergence, and temporal settings with each export. Otherwise, an apparently better result may come from a gentler stereo effect rather than a better depth pipeline.

Inspect the source, the depth sequence, and the rendered stereo output separately. If an edge is already unstable in depth, renderer tuning may only hide it. If depth looks stable but the output trails, inspect the correspondence and state handling. When ground truth is absent, these checks are diagnostics; they do not establish geometric accuracy.

Record processing time and peak memory alongside the visual observations. The official Video Depth Anything repository distinguishes offline inference from an experimental streaming mode and explicitly reports a performance drop for that streaming configuration. That is a useful reminder to evaluate the execution mode the product would actually use. An offline result should not silently become a claim about an interactive workflow.

Budget for the sequence people will watch

For teams building creative conversion tools, the practical consequence is a different acceptance process. A hero image can demonstrate depth separation. It cannot demonstrate that a clip remains watchable through movement, occlusion, and cuts.

A larger estimator may be worth its compute cost. A smaller model with a restrained effect may be sufficient for another use. That decision needs representative footage and repeatable comparisons. It should also include the time someone spends rejecting or repairing an export; a fast render that requires extensive cleanup may be a poor workflow choice.

Stereo Depth Lab remains a local research prototype. Its documented separation between a lightweight renderer and a possible future reconstruction backend is a useful discipline: define what the present system estimates, then test the behavior that viewers actually receive. For video, that behavior lasts longer than one frame.

The Hard Part of an AI Event Guide Is Keeping It Current

Keith Azodeh — Wed, 14 Oct 2026 23:09:42 +0000

Consider a simple event listing: the time is correct on Monday, the venue changes on Thursday, and someone searches for it on Friday. A searchable copy of Monday's announcement can still send that person to the wrong place. Making information easier to find also makes its maintenance more consequential.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

I built AfroTech Guide to make scattered community information easier to navigate. Its public experience includes approved people and events, correction flows, and curated Houston dining recommendations. A connected AI experience adds conversational discovery and planning, with a different release scope from the public website. Not every underlying module is exposed publicly.

The project gives me a useful context for a broader product question: when discovery gets easier, who keeps the information worth discovering?

Discovery and contributions are converging

Google's August 6, 2026 Ask Maps update is an example of this ongoing shift. Alongside richer discovery and planning features, Google described conversational contributions: users can suggest changes, including business hours extracted from a storefront photo. The user confirms the suggestion, and Google's systems review submitted edits.

The contribution flow matters to the discovery experience. A helpful interface needs a way for information about the world to catch up when the world changes. Google's announcement does not establish how a smaller directory should implement that process, but it makes the maintenance problem visible alongside the AI features.

My directory field notes describe a staged pipeline: capture information with provenance, normalize a useful set of fields, curate it, then make it searchable. Those stages provide a place to ask what happens after a record's first publication.

Keep the identity; update the facts

For a comparable event directory, I would give each listing a stable identity independent of its current description. A changed time should update the event people already saved, rather than create a second listing that competes with the first.

Status deserves its own field. Google's event structured-data guidance distinguishes canceled, postponed, and rescheduled events. For canceled events, it advises preserving identifying properties while changing the status. A postponed event with no new date is different from one with a confirmed replacement date.

That guidance concerns Google's search representation. I would use the underlying distinction in an application's own model too: "still exists" and "still happening as originally announced" are separate facts.

A lightweight maintenance record could include the source URL, the current status, when the relevant facts were checked, and when they need another review. These are proposed fields, not a claim about AfroTech Guide's exact schema.

For a concrete example, AFROTECH's official speaker profile identifies my Building AfroTech.guide session, while its official agenda supplies the current time and room. A directory should keep those source links attached to the record so readers can check the organizer's latest details.

Freshness belongs to individual claims

An event's description may remain useful after its ticket availability changes. A restaurant's address may be stable while its opening hours need another check. A single "updated" timestamp can conceal that difference if it changes whenever someone edits punctuation.

For a new guide, I would distinguish editorial edits from factual verification. The review cadence should follow the claim: recheck time-sensitive details close to the event, while giving less volatile information a different schedule. A missing check should remain visible as uncertainty rather than being translated into confident wording.

This is also where product scope matters. If the data does not include current availability, a recommendation should not imply that a seat, ticket, or reservation is available. The interface can still help someone discover the option and reach the source that can answer that question.

Conceptual maintenance cycle proposed in this article, created with AI-written drawing code. Not a product screenshot.

Make a correction easy to submit and possible to review

A correction path needs more than an empty text box. The reviewer needs to know which record is affected, which fact is disputed, and what supports the proposed change. Otherwise, every report becomes a fresh investigation.

I would treat a submitted correction as a proposal until it is checked. That avoids turning a helpful contribution feature into an unrestricted editing channel. The result should also be understandable to the contributor: accepted, unresolved, or declined, with enough context to make another report useful.

Conversational interfaces can support this work without requiring every interaction to be prose. The MCP Apps overview describes interactive views connected to tool results, with text fallback for hosts that do not support the UI extension. For a directory, that creates room for a record card and a focused correction form inside a supported host. It does not supply the review policy or make the underlying information current automatically.

That is a proposed design direction. AfroTech Guide's documented public correction flows and connected experience should not be read as a claim that this exact form is already available in every host.

Budget for the information, not just the interface

For community organizations, event teams, and local-discovery products, my practical conclusion is that directory maintenance should be part of the operating plan. More natural search can expose useful records to more situations. It can expose neglected records just as effectively.

I would measure correction turnaround, how many upcoming events have recently checked details, and how often a recommendation depends on an unresolved report. Those are proposed operational measures, not results reported for my project.

There is a tradeoff. Reviewing every detail continuously would overwhelm a small team. Start with the changes that can waste someone's trip or derail a plan, keep the source visible, and decide who owns the next review. A directory becomes more useful when the next correction has somewhere clear to go.

One Login Is Not an Access Policy

Keith Azodeh — Wed, 14 Oct 2026 18:02:56 +0000

A member and a staff coordinator can belong to the same organization, use the same login system, and need very different access. That difference becomes easy to lose when a product brings several disconnected tools into one place.

Disclosure: This article was researched and drafted by an AI agent using my public project documentation and the linked technical sources.

In my work on The Garden platform, one identity connects member and staff experiences. Permissions follow roles, departments, ownership, and explicit access rules. Sensitive fields are protected on the server, and household schedule sharing depends on consent. The Planning Center replacement remains a staged migration; the public case study does not claim that every workflow has finished rollout.

That combination is the design problem: make the system feel connected while preserving the reasons people should see different parts of it.

Give the task a permission of its own

GitHub's October 13, 2026 app-permissions update provides a timely example. Apps and fine-grained personal access tokens can use repository_creation:write to create repositories without the broader repository_administration:write permission previously needed for that task. The broader permission also covers administrative operations such as deletion and transfer. Organization installation still requires the relevant approval.

The narrower permission separates a legitimate task from powers it does not require. That is a useful product decision as well as a security improvement: an administrator can assess the capability being requested more precisely.

Applied to an organizational application, I would start by naming the action. Updating your availability, assigning someone to a team, and editing a person's private record should be separate decisions. A broad label such as "staff" may be one input to those decisions, but it leaves too much unspecified by itself.

These are illustrative design examples, not a description of additional Garden permission names or a claim about its exact schema.

The data model determines what can stay private

My Firebase security field notes start with data modeling because a rule is easier to understand when the stored data matches the access pattern.

Firestore makes this especially concrete. Its field-access documentation explains that Security Rules authorize document reads as a whole. They cannot allow a client to read one field while hiding another field in the same document. Data requiring different read permissions can be stored in separate documents with their own rules.

That matters when designing a convenient profile object. Combining a directory name with restricted internal information may make the first screen easier to build, but the resulting document becomes the unit of disclosure for direct client reads. Removing a field from the React component cannot undo data already delivered to the browser.

Write access is a separate question. The same Firebase guide describes comparing a document's old and proposed state and allowing changes only to selected fields. Read visibility and permission to change a value deserve independent decisions.

For a new system, I would sketch those decisions before settling the profile schema: which information can be read together, which updates belong to the person, and which values require another authority?

Check the route the request actually takes

There is another distinction to keep visible. Firebase's Security Rules conditions guide states that server client libraries bypass Firestore Security Rules. Their credentials and IAM configuration therefore need separate attention. A backend acting on a user's behalf also needs to enforce the application's authorization decisions.

The same guide explains why rules do not behave like result filters. A client cannot query every document and expect Firestore to quietly return only authorized records; the query must satisfy the relevant constraints.

Those details affect implementation reviews. I would trace a direct client request and a server-mediated request separately, then verify the policy applied on each route. Reviewing the visible button alone does not establish what either route permits.

Test the person who should be refused

The Garden's public documentation describes isolated demonstration data, including a synthetic directory used for validation. It distinguishes implementation checks from completed migration and staff acceptance. That is a useful distinction to keep when discussing access testing, too.

For a comparable application, I would write a short set of refusal scenarios alongside the allowed workflows:

A member requests another person's restricted record directly.
A coordinator attempts an action outside the team they manage.
A former coordinator retries the same action after access is removed.
A user includes a protected field in an otherwise ordinary update.

These are proposed test cases, not reported Garden test results. Each needs an expected decision and a check at the point that enforces it. A successful page load with demonstration data cannot establish all of those properties.

The tradeoff is real: more precise permissions require more policy, more tests, and a way to explain refusals to users. Excessive exceptions can make the system harder to maintain. Start with the distinctions the actual work requires, and add specificity when a concrete workflow needs it.

For teams consolidating software, GitHub's change is a useful reminder that permission design can improve alongside features. A shared identity removes repeated sign-ins. A precise access policy lets that convenience extend across more workflows without handing every person, integration, or future agent the same authority.

A Correct AI Answer Can Still Be an Unusable Workflow

Keith Azodeh — Wed, 14 Oct 2026 15:26:02 +0000

An extracted price is only useful if someone can compare it with the next supplier's offer. An edited sentence is only useful if it lands on the right page. Those sound like ordinary software requirements. They are also where an AI feature starts becoming a working system.

Disclosure: This article was researched and drafted with AI using my public project documentation and the linked technical sources.

Looking across my pricing, editing, and archive-search projects, I see a recurring design question: what has to be true before a model's output can become something another person relies on?

Conceptual diagram generated with AI-written drawing code, based on public project documentation.

The price needs somewhere to go

In my TMC pricing project, supplier information arrived through emails, lists, and attachments. The workflow extracted product, size, price, region, and supplier into structured records for comparison. An early prototype used DeepSeek R1 for interpretation.

Extraction was one stage. The wider work included a central pricing repository, reviewable reports, and quote and invoice workflows. The public case study describes a delivered 2023–2025 engagement; it should be read as project history, not a fresh benchmark of today's models.

The useful unit here is a comparable pricing record. If two offers describe different sizes or regional contexts, putting their prices beside each other does not settle the comparison. A fluent extraction can still leave the operational question unresolved.

For a similar system, I would evaluate the handoff explicitly: can a reviewer trace the extracted value to its source, understand the product description, and see what remains uncertain? Those are proposed evaluation questions, not additional features or measured results claimed for this project.

A paragraph belongs to a particular version

My Okeike editor approaches a different problem: making focused changes to existing websites. It combines recoverable drafts, AI-proposed edits, and publishing through GitHub commits and the existing Firebase deployment path.

Its patching layer uses constrained selectors and structured fields. Source-version fingerprints and base-file identifiers help recognize when the file underneath a draft has changed. Static HTML and structured application content have different patching paths.

That detail matters more than whether the suggested sentence reads beautifully. A proposed edit needs a target and a source version. Otherwise, a correct sentence can become an incorrect change.

This also gives review a manageable scope. Someone can inspect a focused patch without reconstructing why an entire page was regenerated. The editor remains under development; a working publication path is different from claiming every client workflow is finished.

An archive answer needs its surrounding record

For Illumia's archive tool, I built around the relationship between service cases and their work entries. Search results preserve the parent case context, so a matching note can be understood within its history.

The Claude Desktop connection exposes six bounded, read-only retrieval tools. Counts and totals come from database queries. The assistant does not receive arbitrary SQL or write access, and the browser and assistant share the retrieval service.

The implementation was tested with synthetic records. Actual archive relevance checks and workplace acceptance are separate steps. Keeping that distinction visible is part of describing the system honestly.

This example changes the evaluation target again. An answer can quote a real note and still mislead if it leaves out the later work that resolved the issue. Retrieval quality includes preserving enough context for a person to check the interpretation.

Why this matters as agent tooling expands

GitHub's October 12, 2026 guide to teaching Copilot about a codebase separates repository instructions, repeatable skills, custom agents, and MCP connections. That is useful context for the current move toward agents embedded in existing development workflows.

My reading is that these layers make the surrounding system increasingly important. Instructions describe conventions. Tools expose capabilities. The application still needs to decide which state changes are valid and how their results can be checked.

Anthropic's April 2026 Managed Agents engineering article makes a related architectural point at infrastructure scale: session history, the agent loop, and execution environments can be separated so components can fail or be replaced independently. That is a vendor's architecture account, not evidence that every application needs the same infrastructure.

For smaller teams, the practical implication is more modest: define the handoff before adding more autonomy. Specify the record being created or changed, the evidence that supports it, and what happens if the source changes or the action fails.

There is a cost. Version checks, review screens, and durable records add implementation work. Too much review can also recreate the manual process the automation was supposed to improve. The right boundary depends on the consequences of a mistake and how easily someone can recover.

In a project review, I would ask someone to follow one output all the way to its destination. Find the supplier offer behind the price. Locate the page version behind the patch. Open the case history behind the answer. The point where that trail breaks is a concrete place to improve the system.

The Browser Is the New Operating System for AI Agents

Keith Azodeh — Wed, 29 Apr 2026 17:56:12 +0000

The future AI agent will not just answer questions in a chat window.

It will open tabs.

It will fill forms.

It will read dashboards.

It will compare options.

It will submit requests.

It will update records.

It will move through the web like a trained employee moving through digital hallways.

That is why I think the browser is quietly becoming the operating system for AI agents.

Not because the browser replaces Windows, macOS, or Linux in a literal sense. I am talking about the browser as the place where work actually happens.

For millions of people, the browser is already the real workstation.

Job boards. CRMs. Billing portals. Scheduling tools. Medical intake forms. Government websites. School portals. Analytics dashboards. Admin panels. CMS editors. Banking tools. Applicant tracking systems. Internal business apps.

The work is in the tabs.

So if AI is going to do real work, eventually it has to touch the tabs.

Chat was the introduction. Action is the next layer.

The first mainstream AI wave trained people to talk to machines.

Ask a question. Get an answer. Draft an email. Summarize a document. Generate code. Explain a concept.

That was important. It gave people a new interface for intelligence.

But the next wave is not just intelligence that talks back.

The next wave is intelligence that acts.

And action requires surfaces.

A chatbot can tell you what to do. A browser agent can actually move through the workflow where the task lives.

That distinction matters.

If a job application lives inside an ATS portal, the agent has to interact with the portal.

If a client website needs an update, the agent has to interact with the editor or content system.

If a business workflow happens in a CRM, the agent has to read and update the CRM.

If a customer books an appointment through a web form, the agent has to understand the form, the schedule, and the rules around submission.

Before AI can “do work,” it has to touch the same surfaces where work already happens.

Most work already happens in the browser

Developers love clean systems.

APIs. SDKs. Webhooks. Structured data. Good documentation. OAuth flows that behave. Everything neat and properly versioned.

Real life is not always that generous.

A lot of work still happens through browser interfaces because the browser is the shared surface everyone already understands.

Employees log into dashboards.

Applicants fill out forms.

Customers book appointments.

Admins update pages.

Owners check analytics.

Teams move information from one portal to another because nobody has built the perfect integration.

The browser became the universal adapter for modern work.

That is why browser automation is not a gimmick.

It is infrastructure.

A browser agent is not interesting because it clicks buttons. It is interesting because it can operate in the messy middle between humans and software that was never designed for AI.

APIs are great, but the world still runs on forms

APIs are better when you can get them.

They are structured. They are faster. They are more reliable. They are easier to monitor. They are usually the right way to build serious integrations.

But not every system exposes the API you need.

Some APIs are expensive.

Some require approval.

Some do not include the specific workflow the user actually needs.

Some tools have APIs, but the customer does not have access to them.

Some industries are full of old portals, half-modern dashboards, vendor-locked systems, and forms that feel like they were designed during a lunch break in 2011.

That is where the browser matters.

A form is just an API with a face.

It has fields. It has validation. It has state. It has submission rules. It has permissions. It has consequences.

Humans already know how to operate forms. The question is whether AI can learn to operate them safely, transparently, and with the right approval gates.

That is a major shift.

Exempliphai exists because job applications are thousands of doors

Job applications are a perfect example of why the browser matters.

There is no single clean API for applying to every job on the internet.

There are job boards. Company career pages. ATS systems. Profile forms. Resume uploads. Screening questions. Demographic fields. Salary expectations. Work authorization fields. Custom questions. Cover letter boxes. Different layouts. Different rules. Different levels of friction.

If you are applying manually, you feel that fragmentation immediately.

That was part of why I built Exempliphai.

I was tired of answering the same fields over and over again. I wanted a system that could remember my context, help me move faster, find fresh opportunities, and package the repetitive parts of applying into something a normal person could actually use.

The first version of that kind of automation can be messy. Local workflows, browser control, test servers, and tools that make sense to the builder but would scare a normal user.

The product challenge is different.

You have to turn that chaos into a safe interface.

You have to reduce unnecessary permissions.

You have to make the user feel in control.

You have to show what is happening.

You have to create trust.

That is the real work behind browser-based AI agents.

The point is not simply “AI can fill forms.”

The point is that the browser becomes the action layer between a person’s intent and a fragmented digital world.

Okeike is the other side of the same shift

Job applications are one browser-native workflow.

Website editing is another.

That is where a project like Okeike fits into my thinking.

A lot of people need websites updated. They need pages changed, content cleaned up, SEO improved, forms adjusted, images swapped, service pages rewritten, and project pages structured.

But they do not always want to open a code editor. They do not want to deploy a site. They do not want to understand routing, components, metadata, build tools, or how a static site generator works.

They just want the site to reflect the business.

That is another browser-agent opportunity.

AI-assisted web editing.

Client-accessible page control.

Structured content.

SEO metadata.

Safe publishing flows.

Human approval before changes go live.

Again, the browser is not just a window. It is the workbench.

The Watch Dogs problem: everything connected, everything exposed

Watch Dogs was broad, but it got one thing right: the world was becoming hyperconnected.

Cameras. Doorbells. Cars. Phones. Payment systems. Databases. Location systems. Access control. Public infrastructure. Private dashboards. Internet of Things devices. Blockchains. APIs. Surveillance systems.

We already live in a connected society. We just do not always feel the full weight of that connection because most people are not touching all the layers at once.

AI agents change that.

An agent with access to the browser may be able to touch dozens of systems through one surface.

That is useful.

It is also dangerous.

The more connected the workflow, the more important permissions become.

What can the agent read?

What can it click?

What can it submit?

What can it delete?

What can it purchase?

What can it say on behalf of the user?

What requires approval?

What gets logged?

What happens when it is wrong?

If you build browser agents without answering those questions, you are not building automation. You are giving a fast system a blindfold and a set of keys.

Browser permissions are product design, not paperwork

Chrome extensions already force builders to think about permissions. Chrome’s extension documentation separates permissions, optional permissions, content script matches, host permissions, and optional host permissions. That matters because users deserve to know what a tool can access.

This is not just a technical requirement.

It is product strategy.

The more powerful your browser agent is, the more trust you have to earn.

A tool that can read the current page is different from a tool that can read every page.

A tool that can fill a field is different from a tool that can submit the form.

A tool that can draft a message is different from a tool that can send it.

A tool that can suggest an action is different from a tool that can take that action under your name.

The interface should make those boundaries visible.

Users should know when the agent is observing, drafting, editing, submitting, or waiting for approval.

Invisible automation feels magical until it makes a mistake.

Visible automation builds trust.

The legal and consent layer cannot be skipped

There are some things AI should not do blindly.

Agreeing to terms.

Signing contracts.

Making financial commitments.

Submitting legally sensitive information.

Giving medical, legal, or financial advice without verification.

The FTC has warned that AI responses can be inaccurate, misleading, or made up, and that people should not rely solely on chatbots for medical, legal, or financial advice. That principle applies directly to browser agents.

Once an AI can act in the browser, it can cause real-world consequences.

That does not mean we stop building.

It means we build with layers.

Read-only actions.

Draft actions.

Suggested actions.

Approval-required actions.

Blocked actions.

Logged actions.

Reversible actions.

High-stakes actions.

That is how you keep humans in control while still letting AI carry the repetitive weight.

What developers should build next

If you are a developer looking at this space, do not just build another chat wrapper.

Build systems that understand workflows.

Start with one repeated browser-based process.

Map every step.

Find the surfaces.

Separate reading from writing.

Separate filling from submitting.

Add confirmation gates.

Log actions.

Handle errors like a real product.

Show the user what the agent is about to do.

Let them approve, edit, reject, or take over.

The best browser agents will not feel like ghosts in the machine.

They will feel like power tools.

Fast, useful, controlled, and dangerous only when used carelessly.

The browser is where AI learns to work

The chat window was AI’s introduction.

The browser is where AI starts working.

That shift is bigger than people realize.

Because once agents can move through tabs, forms, dashboards, and portals, they can start interacting with the real operating layer of modern life.

Not in theory.

In the messy workflows people already use every day.

Job applications. Client websites. Business dashboards. Scheduling tools. CRMs. Portals. Admin panels.

The old internet was built for humans clicking through pages.

The next internet will still have humans, but more and more of the clicking, reading, drafting, comparing, and filling will be handled by agents under human direction.

That is the future I am building toward.

Not AI as a toy.

AI as an action layer.

AI as a bridge between intent and execution.

AI as a worker moving through the digital hallways where work already lives.

Do not wait until every platform has a perfect API.

The work is already in the browser.

That is where the agents are going.

Sources and further reading

Chrome Developers, Declare permissions
Chrome Developers, User controls for host permissions
FTC, Operation AI Comply: Detecting AI-infused frauds and deceptions
Keith Azodeh, project hub: asaday.co

Build vs. Buy vs. Prompt Is the Wrong AI Question

Keith Azodeh — Wed, 29 Apr 2026 17:40:37 +0000

Build vs. Buy vs. Prompt Is the Wrong AI Question

Everyone is arguing about the wrong layer.

Should you build your own AI tool?

Should you buy a SaaS platform?

Should you just prompt ChatGPT, Claude, Gemini, or whatever model is winning the group chat this week?

That question sounds practical, but it is usually too shallow.

It is like arguing about which stove is best while nobody has a kitchen, a menu, ingredients, a chef, a reservation system, a cleaning process, or a way to charge customers.

The stove matters.

But the stove is not the restaurant.

That is how a lot of people talk about AI right now. They confuse the model with the product. They confuse prompting with automation. They confuse a demo with an operating system. They confuse “the AI answered me” with “the workflow is solved.”

The real AI stack is not one thing.

It is layers.

Prompts, context, memory, interfaces, tools, APIs, permissions, logs, evaluations, user experience, data flow, pricing, onboarding, support, and business logic all matter.

If you ignore those layers, you do not have an AI product.

You have a magic trick that breaks the moment real life touches it.

The model is not the product

Models are engines.

They are powerful engines. They can reason, summarize, classify, draft, translate, plan, write code, extract information, and sometimes surprise you in ways that feel almost illegal.

But an engine sitting on the floor is not a car.

GPT, Claude, Gemini, Grok, open-source models — these are engines. They can create leverage, but only when they are installed inside a system that knows what to do with that leverage.

A product needs an interface.

A product needs users.

A product needs permissions.

A product needs context.

A product needs a reason to exist when the user closes the chat window.

A product needs to remember things, take actions, handle errors, explain itself, recover from failure, protect data, and make money.

That is why “we use AI” means almost nothing by itself.

Where?

For whom?

With what data?

Connected to what tools?

With what permissions?

What happens when it is wrong?

Who approves the final action?

What gets logged?

How do you measure whether it actually helped?

Those questions are where the real work starts.

Prompting gets you started. It does not make you durable.

Prompting is useful. I use it constantly.

But prompting by itself is not a moat.

A prompt is a spark. It can start the fire, but it is not the fireplace, the fuel supply, the ventilation, the safety system, or the building the fire is supposed to heat.

Prompting helps you think.

Prompting helps you draft.

Prompting helps you test ideas.

Prompting helps you move faster.

But if the workflow still depends on a human copying information into a chat window, copying the answer out, pasting it into another tool, checking six tabs, and manually deciding what happens next, then you did not automate the workflow. You just added a faster assistant to a slow pipeline.

That is fine at the beginning.

It is not enough when the workflow becomes important.

The value starts when AI moves from conversation to integration.

The real AI stack

When I think about an AI product or automation system, I think in layers.

Not because layers sound fancy. Because layers keep you honest.

1. The interface layer

This is where the user touches the system.

It could be a chat window, a voice call, a browser extension, a dashboard, a mobile app, a form, a command palette, or a backend admin panel.

The interface matters because users do not experience your model. They experience your product.

A brilliant AI system with a confusing interface will feel broken.

A simple interface over a useful workflow can feel like magic.

This is one reason I care so much about packaging. A personal automation can be messy. A product cannot. Users should not need to run a server, understand a repo, perform a git push, or read a technical manual to get value.

The complexity should be behind the curtain.

2. The context layer

This is what the AI knows before it speaks.

Context can include user profiles, company data, CRM records, documents, past conversations, preferences, policies, files, browser state, or structured memory.

Without context, the model guesses.

With context, the model can help.

This is the difference between asking an AI, “Write me a cover letter,” and giving it your actual history, the job description, your preferred tone, your projects, your constraints, your location, your salary range, and the parts of your background that matter for that specific role.

One is generic.

The other is useful.

Context is where AI starts becoming personal without becoming fake.

3. The reasoning layer

This is where the model interprets the task.

It decides what the user wants, what information matters, what steps are required, and what uncertainty exists.

But reasoning cannot float in the air. It has to be connected to rules and constraints.

What should the system do when it is uncertain?

What should it refuse?

When should it ask for clarification?

When should it escalate to a human?

When should it stop?

This is where a lot of AI demos fall apart. They look impressive when everything goes right, but the moment the user goes off-script, the system becomes a confident mess.

A good reasoning layer needs humility built into it.

4. The tool layer

This is where AI stops talking and starts acting.

APIs. Browser actions. Database writes. Calendar events. Emails. CRM updates. File generation. Payment workflows. Form submissions. Search. Retrieval. Code execution.

This layer is where the magic becomes dangerous.

Because the moment an AI can take action, permissions matter.

Read actions are different from write actions.

Drafting an email is different from sending it.

Filling a form is different from submitting it.

Suggesting a contract clause is different from agreeing to terms under your legal name.

If you do not separate these layers, you create systems that are either too weak to be useful or too dangerous to trust.

5. The safety layer

Safety is not just “do not say bad things.”

Safety is permissions, review, visibility, audit logs, rate limits, fallbacks, escalation, and human approval.

This is where you decide what the AI is allowed to do alone and what requires a human in the loop.

I believe in automation. Heavy.

But I do not believe in blindly handing legal, financial, medical, or identity-sensitive authority to a system without review.

The question is not just whether AI can reason.

The question is whose reasoning it follows when it acts on your behalf.

6. The evaluation layer

If you cannot measure the system, you cannot improve it.

Every serious AI product needs some way to inspect performance.

What did the model decide?

What source did it use?

What tool did it call?

What failed?

What did the user correct?

What edge case keeps repeating?

Where did it hallucinate?

Where did it save time?

Where did it create risk?

Evaluation is not glamorous, but it is the difference between a toy and infrastructure.

7. The business layer

This is the layer builders love to ignore until it punishes them.

Who is the user?

What pain is being solved?

How often does that pain happen?

What is the cost of doing nothing?

Who pays?

How do they onboard?

How do they trust it?

How do they get support?

How does the product survive when the model price changes, the API changes, or a competitor copies the surface-level feature?

AI does not remove business fundamentals.

It exposes people who never had them.

Prompt vs. buy vs. build

Now we can talk about the original question.

Should you prompt, buy, or build?

The answer depends on whether the workflow is casual, operational, or core.

Prompt when the task is occasional

Prompting is great when the task is low-risk, flexible, and not repeated enough to justify infrastructure.

Brainstorming. Drafting. Summarizing. Learning. Exploring. Thinking through ideas.

Prompting is the fastest way to start. It is also the easiest layer for someone else to copy.

Buy when the workflow is standard

Buying makes sense when the problem is common and your business does not need deep customization.

Customer support. Meeting summaries. Basic email drafting. Standard CRM features. Generic knowledge base bots.

If the workflow is not unique, buying can be smarter than building.

But buying has limits. You inherit someone else’s assumptions, interface, permissions, pricing, roadmap, and constraints.

Build when the workflow is core

Building makes sense when the workflow is central to your advantage.

If it touches your proprietary data, your customer experience, your operational bottleneck, your product experience, or your unique process, building or deeply customizing may create leverage that off-the-shelf tools cannot.

That is where developers win.

Not by slapping a chatbot on a page.

By turning a messy workflow into a system.

Why companies get stuck in pilot mode

A lot of companies are using AI, but many are still stuck experimenting instead of scaling. McKinsey’s 2025 State of AI report says AI use is broadening, but most organizations remain in experimentation or piloting phases rather than capturing enterprise-level value at scale.

That tracks with what I see.

Companies do demos.

They run pilots.

They test a chatbot.

They buy a tool.

They announce “AI initiatives.”

But the workflows do not change because the AI never gets connected to the system of record, the approval process, the real customer journey, or the operational bottleneck.

It becomes a chandelier.

Looks nice.

Makes people feel modern.

Does not move water through the pipes.

AI has to be installed like plumbing, not decoration.

Agents are workers with tools, not magic spirits

Everyone loves the word “agent” right now.

But an agent is not magic.

An agent needs a goal.

It needs context.

It needs tools.

It needs guardrails.

It needs feedback.

It needs memory.

It needs an escalation path.

Without those, you do not have an agent. You have a chatbot with ambition.

IBM’s 2025 CEO study found that many CEOs are actively adopting AI agents and preparing to scale them, while also pointing to challenges like disconnected technology and the need for integrated data architecture. That is the real battlefield.

Agents are not valuable because they can talk.

They are valuable when they can move through a workflow safely.

Where developers create leverage

Developers create leverage in the boring places.

Connecting systems.

Designing interfaces.

Managing permissions.

Structuring context.

Logging actions.

Building fallback logic.

Reducing friction.

Turning business pain into a repeatable workflow.

That is the work.

The model is important, but the model is not the whole game. The game is orchestration.

The game is building the bridge between human intent and machine action.

The game is making the system usable enough that a nontechnical person can get value without seeing the chaos underneath.

The wrong question hides the right one

Build vs. buy vs. prompt is not useless.

It is just incomplete.

The better question is:

What layer of the stack are we missing?

Maybe you need a prompt.

Maybe you need a tool.

Maybe you need an interface.

Maybe you need cleaner data.

Maybe you need a human approval step.

Maybe you need an API integration.

Maybe you need to stop pretending AI is the solution when the actual problem is a broken process.

That is why I keep coming back to systems.

Prompting gets you started.

Integration gets you paid.

Systems create leverage.

If you are a developer, founder, operator, or business owner trying to figure out where AI belongs, start with the workflow. Map the pain. Find the repetitive motion. Find the decision point. Find the data. Find the tool the AI needs to touch. Find the place where a human still needs control.

Then decide whether to prompt, buy, or build.

Not before.

Sources and further reading

McKinsey, The State of AI in 2025: Agents, innovation, and transformation
IBM, CEOs Double Down on AI While Navigating Enterprise Hurdles
FTC, Operation AI Comply: Detecting AI-infused frauds and deceptions
Keith Azodeh, project hub: asaday.co

Your Digital Self Will Outlive You. Your Resume Already Does.

Keith Azodeh — Wed, 29 Apr 2026 17:34:27 +0000

Altered Carbon imagined consciousness stored in a stack.

We are not there yet. Not really. You cannot pull a person out of one body, drop them into another, and keep the same mind running like software on a new machine.

But your professional identity already lives outside your body.

Your resume. Your LinkedIn. Your GitHub. Your portfolio. Your application history. Your screenshots, articles, posts, case studies, pitch decks, search results, side projects, and half-finished ideas sitting in folders you forgot existed.

That is already a primitive version of a digital stack.

It is not your soul. It is not your full identity. But it is the version of you that gets searched, filtered, judged, ranked, summarized, invited, rejected, remembered, and misremembered.

And now AI is beginning to touch that stack.

That means your digital self is about to become editable at scale.

Damn.

That should excite you and unsettle you at the same time.

Because the future identity problem is not just privacy. It is authorship.

Who writes the version of you that the world sees?

You? The platforms? Recruiters? Search engines? AI models? Old resumes? Random public records? A stale LinkedIn headline you wrote three years ago because you needed something to put there?

Do not wait until the internet decides who you are.

Build the stack yourself.

Your resume is not your identity, but it acts like it

A resume is not your career.

It is a compressed screenshot of your career, usually taken at the worst possible resolution.

Think about what a resume actually does. It takes years of work, learning, problem solving, relationships, projects, pivots, late nights, failures, wins, and technical context, then squeezes all of that into one or two pages.

It asks you to summarize your professional life in bullet points.

It asks you to turn human complexity into keywords.

It asks you to remember every relevant detail on command, but only include the details that fit the specific job, the specific company, the specific recruiter, the specific ATS system, and the specific moment.

That is not identity. That is lossy compression.

And once it gets uploaded, it starts acting like identity.

An ATS reads it. A recruiter skims it. A hiring manager compares it against someone else. A model summarizes it. A platform stores it. A search engine indexes the page attached to it. Suddenly, this little compressed document becomes your representative in rooms you never entered.

It starts speaking for you.

The problem is not that resumes exist. The problem is that we still treat them like static documents when careers are becoming dynamic systems.

You are not one PDF.

You are a database of experience, context, skills, projects, judgment, preferences, constraints, and stories.

The resume is just one output.

AI makes identity editable at scale

Before AI, updating your professional identity was annoying but limited.

You rewrote your resume manually. You adjusted your LinkedIn headline. You changed your portfolio copy. You asked a friend to look over your bio. Maybe you paid someone to clean it up.

It was slow enough that people did not constantly reinvent themselves.

Now, that bottleneck is gone.

AI can rewrite a resume in seconds. It can generate a cover letter. It can tune a LinkedIn summary. It can summarize a GitHub repository. It can turn a voice note into a founder story. It can build a portfolio page. It can create ten versions of your bio for ten different audiences.

This is powerful.

It is also dangerous.

Because when identity becomes easy to edit, the line between clarity and performance gets thinner.

There is a clean version of this future and a dirty version.

The clean version uses AI to help you remember what you actually did, explain it better, and present it in the right context.

The dirty version uses AI to manufacture a professional character loosely inspired by you.

That distinction matters.

Tailoring is not lying.

Translation is not fabrication.

If I built a product, led a workflow, integrated tools, designed a system, wrote code, or solved a business problem, AI helping me surface the right detail for the right role is not fake. That is clarity.

But if AI starts inventing credentials, employers, metrics, awards, clients, or experience that never happened, that is not optimization. That is fraud with better formatting.

The future belongs to people who understand the difference.

Exempliphai and the idea of externalized memory

One of the reasons I built Exempliphai was because job applications were forcing me to repeat myself like a machine.

Name. Email. Work history. Education. Salary expectations. Preferences. Demographics. Why are you a good fit? Upload resume. Re-enter everything already on the resume. Do it again. Do it again. Do it again.

After a while, the job search starts to feel less like presenting yourself and more like working on an assembly line where the product is your own identity.

The deeper frustration was not just the typing.

It was the memory problem.

A lot of us have done too many things to fit neatly into one page. We have touched projects, systems, tools, clients, workflows, and responsibilities that do not come to mind instantly when a job form asks some generic question.

That is where AI becomes interesting.

Not because it can make you sound fancy.

Because it can help you remember.

It can become a mirror with memory.

If you give it enough honest context, it can help retrieve pieces of your own experience that you may have forgotten were relevant. It can connect dots across your career. It can say, “This role is asking for X, but remember when you did something similar on Y?”

That is not cheating.

That is externalized memory.

And externalized memory is one of the most underrated parts of the AI shift.

Humans forget. We compress. We undersell ourselves. We over-focus on the most recent thing. We fail to connect experiences that actually belong together.

AI, when used correctly, can help rebuild that context.

The value is not just filling forms faster.

The value is remembering better at the moment the memory matters.

Your online presence is already being used against or for you

Even if you do not think about personal branding, personal branding is thinking about you.

Search your name. What comes up?

LinkedIn? GitHub? Old pages? A project? A random mention? A half-empty profile? Something you wish was not there?

That first page of results is not neutral. It is a reputation surface.

It tells a story, even when you never intentionally wrote one.

And in a world where AI tools can summarize people quickly, your public footprint becomes raw material. It becomes training context for humans and machines trying to understand you.

If your digital presence is empty, outdated, messy, or controlled entirely by third-party platforms, you are letting the internet decide the story.

That is a terrible strategy.

Especially now.

Because your digital self will increasingly be assembled automatically. Recruiters will use tools to summarize candidates. Clients will search before booking. Investors will look for signals. Employers will compare your resume against your online footprint. People will ask AI who you are and what you have built.

The question is not whether your digital self exists.

It does.

The question is whether you are actively building it or passively inheriting whatever the web collected.

Authorship is the real fight

People love to talk about privacy, and privacy matters.

But authorship may matter just as much.

Who gets to define you?

A platform profile? A recruiter note? A resume parser? A search engine snippet? A model summary? A stale bio? A bad article? A public record? A random algorithm trying to guess your relevance?

If you do not build your own professional stack, other systems will build one around you.

And they will not ask for your permission.

This is where the Altered Carbon metaphor becomes useful.

In that world, the stack holds the person.

In our world, your digital stack holds the professional version of you that markets, institutions, platforms, and employers interact with.

It is not consciousness.

But it is leverage.

A strong digital stack protects you. It gives people better evidence. It lets your work speak when you are not in the room. It makes your experience searchable, linkable, and understandable. It creates a layer of armor between you and whatever random result, old resume, or third-party summary tries to define you.

That is why the personal website is not dead.

That is why the portfolio matters.

That is why GitHub matters.

That is why articles matter.

That is why project pages matter.

That is why your resume should not just be a PDF sitting in a folder.

Your professional identity should be a living system.

The future resume will be dynamic

The resume of the future will not be one static file.

It will be structured data.

It will understand your projects, skills, industries, responsibilities, tools, outcomes, writing samples, links, constraints, and preferences.

It will generate different outputs depending on context.

A healthcare software role should not get the same version of you as an AI automation role. A startup founder should not read the same framing as an enterprise recruiter. A client looking for a web app does not need the same emphasis as a company looking for technical sales support.

Same person.

Different lens.

That is not fake.

That is communication.

The old resume forces one version of you to do every job. The new resume should behave more like a database with a smart query layer.

Ask the right question, get the right version.

This is where tools like Exempliphai become more than autofill.

The autofill is useful. The application tracking is useful. The role-specific answers are useful. But the bigger idea is that your career data can become operational.

It can move.

It can adapt.

It can help you show up faster and more clearly in systems that are already automated on the hiring side.

Because make no mistake: hiring has been automated for years.

ATS systems, resume parsers, ranking tools, AI-assisted notes, automated screening, and algorithmic decision systems are already part of the employment landscape. The EEOC has warned that AI and algorithmic tools used in hiring can mask bias or create discriminatory barriers, and that employment laws still apply to these systems. (EEOC)

If the hiring side is automated, the applicant side cannot stay manual forever.

Nature abhors a vacuum.

The system will rebalance.

Keep the human in the loop

I am aggressively pro-automation.

But not blindly.

There are things AI should help with, and there are things AI should not silently take over.

It should help you remember your experience.

It should help you tailor your resume.

It should help you fill repetitive fields.

It should help you build a better professional website.

It should help you turn messy experience into clear language.

But when the action is tied to your legal name, your consent, your money, your health, your rights, or your reputation, the human needs to stay in the loop.

Automation should carry the bags.

It should not sign your name to a contract you did not read.

The FTC has warned that AI outputs can be inaccurate, inadequate, misleading, or made up, especially when companies overstate what AI tools can safely do in high-stakes contexts. (FTC)

That is the line.

Use AI to extend memory, reduce repetition, and improve clarity.

Do not hand over authorship of your life.

Build the stack before someone else does

The status quo is not an option.

The old way was: create a resume, apply manually, hope someone sees it, maybe update LinkedIn every few months, and let search results be whatever they are.

That is too passive now.

The new way is active.

Own your name.

Own your website.

Own your project pages.

Own your case studies.

Own your resume data.

Own your public narrative.

Own the links between your work.

Own the context that AI systems will eventually summarize.

Because your digital self is not going away. It is only becoming more important.

People will search it. Systems will parse it. Models will summarize it. Recruiters will compare it. Clients will use it to decide whether to trust you.

So build it intentionally.

Do not wait until a platform, institution, recruiter, or algorithm decides where you fit in the hierarchy.

You are capable of building the stack now.

Start with one page. One project. One article. One clean resume. One portfolio. One system that remembers what you have done better than your tired brain can on command.

Your digital self will outlive this moment.

Make sure it is actually yours.

Sources and further reading

EEOC: Artificial Intelligence and Algorithmic Fairness Initiative
FTC: Operation AI Comply: Detecting AI-infused frauds and deceptions
Keith Azodeh: asaday.co
Dev.to: Keith Azodeh
Medium: @keithazodeh

Recency Is King: Why the First 50 Job Applicants Play a Different Game

Keith Azodeh — Wed, 29 Apr 2026 02:48:14 +0000

Two people can have the same résumé, same skills, and same experience—but if one applies when the job is posted and the other applies after 900 people, they are not playing the same game.

The job search has a timing problem.

People talk about qualifications, keywords, networking, résumés, referrals, and interviews.

All of that matters.

But timing matters too.

A lot more than people want to admit.

A job posted ten minutes ago is not the same opportunity as a job posted ten days ago.

The title may be the same. The company may be the same. The application form may be the same. But the human context around that job is completely different.

Early in the process, the role still has energy.

The recruiter is still fresh.

The applicant pool is still manageable.

The hiring manager may still be paying attention.

The comparison set is still forming.

Later, that same job becomes a flood.

And once the flood opens, individual attention becomes expensive.

That is why I say:

Recency is king.

The job market pretends timing is neutral

On the surface, job applications look like a fair queue.

Everybody submits.

Everybody gets reviewed.

The best candidates rise to the top.

That sounds nice.

But anyone who has actually been inside a messy human system knows that is not how attention works.

Recruiters are human.

Hiring managers are human.

Teams are busy.

Budgets change.

Priorities shift.

Inbox fatigue is real.

Even when companies use applicant tracking systems, AI filters, automated rankings, templates, and screening tools, the overall process still runs through human bottlenecks.

The EEOC has held hearings on the increasing use of AI and automated systems in employment decisions, including recruitment and hiring. That means the system is already technical, already automated, and already complex.

Source: EEOC hearing on AI and automated systems in employment decisions

But automation does not remove human attention limits.

It just rearranges where they show up.

And that is where recency matters.

The first batch advantage

The first applicants do not just apply to the job.

They help define what the recruiter thinks the job market looks like.

That is the part people miss.

When a role opens, the company may have an idea of what it wants. But that idea is often still flexible. The recruiter is calibrating. The hiring manager is clarifying. The team is figuring out what kind of candidates are actually available.

The first batch shapes the conversation.

If the first ten applicants are weak, the eleventh solid applicant may look amazing.

If the first fifty applicants all have one kind of background, a different profile may stand out.

If the recruiter sees your application while the role is still new, you are entering before the job becomes another overloaded queue.

That does not guarantee anything.

But it changes the game.

The same résumé can feel different depending on when it appears.

Fresh fruit at the market gets handled differently than fruit buried at the bottom of the pile.

Same fruit.

Different timing.

Recruiters do not have infinite attention

This is not an attack on recruiters.

It is the opposite.

It is an acknowledgment that recruiters are human.

If a role gets hundreds or thousands of applicants, nobody is giving every résumé the same emotional energy, curiosity, and patience.

That is not realistic.

At some point, review becomes triage.

At some point, the system starts looking for reasons to say no faster.

At some point, attention collapses.

The first batch gets a different kind of recruiter than the thousandth applicant.

That sounds harsh, but it is true.

The job market is not just a meritocracy.

It is also a timing system.

A queue system.

A filtering system.

A human attention system.

And if you ignore that, you are playing the game with one eye closed.

Manual job search makes you late

This is one of the reasons I started building around job automation.

Manual job search is slow by design.

You have to find the role.

Read the description.

Decide if it fits.

Edit your résumé.

Write or adjust a cover letter.

Create yet another account.

Re-enter your name.

Re-enter your phone number.

Re-enter your address.

Re-enter your work history.

Re-enter your education.

Answer demographic questions.

Answer custom questions.

Upload the same file.

Check the same boxes.

Then do it again.

And again.

By the time you finish carefully applying to five jobs, someone else using automation may have found fifty fresh postings, tailored their context, and entered the pipeline earlier.

That does not mean they are better.

It means they are positioned better.

In a gold rush, early movers do not need perfect tools.

They need enough tools to start digging before the crowd shows up.

The real advantage is not speed. It is context.

Some people hear “AI job automation” and think the goal is to blast low-quality applications everywhere.

That is not the future I am interested in.

Speed without context is spam.

The real advantage is speed plus relevance.

That means a system should know:

Your work history
Your education
Your projects
Your skills
Your preferences
Your salary expectations
Your location constraints
Your strengths
Your previous answers
The kind of roles you actually want
Which parts of your background matter for this specific job

The power is not just autofill.

The power is contextual memory.

A lot of people have done more than they can remember on demand. They have touched tools, projects, systems, workflows, and responsibilities that never made it onto a one-page résumé.

So when a fresh job appears, the right system should help answer:

What part of my real background matters here?

That is the shift.

Not fake experience.

Not mass deception.

Not pretending to be someone else.

Just better retrieval.

Better timing.

Better presentation.

What should be automated

If you are a job seeker, there are parts of the process that should absolutely be automated.

There is no moral victory in manually typing your name into the 300th form.

Automate the repetitive parts:

Basic personal information
Work history
Education history
Salary preferences
Location preferences
Job tracking
Fresh job discovery
Role-fit summaries
Résumé versioning
Cover letter drafts
Application status tracking
Repeated demographic and eligibility fields where appropriate
Matching your real experience to job requirements

That is not laziness.

That is refusing to waste human brainpower on clerical repetition.

Your brain should be used for strategy.

Not retyping your phone number.

What should stay human

I am pro-automation, but I am not reckless.

There are parts of the process that should stay human-controlled.

Do not blindly let AI agree to legal terms under your name.

Do not let AI invent experience.

Do not let AI answer something deeply personal without review.

Do not let AI commit you to something you do not understand.

Do not let AI turn your job search into a spam cannon.

Automation should carry the bags.

It should not sign your name to a contract you did not read.

The future is not “remove the human.”

The future is “put the human where judgment matters.”

The applicant side has to catch up

The hiring side is already changing.

AI is entering recruiting. Automated systems are shaping employment decisions. Workers themselves are starting to use AI more in their jobs. Pew Research Center reported in 2025 that 21% of U.S. workers say at least some of their work is done with AI, up from 16% roughly one year earlier.

Source: Pew Research Center: About 1 in 5 U.S. workers now use AI in their job

That number will not stay still.

The people who learn how to use these tools now will not just save time.

They will build workflows.

They will build systems.

They will see opportunities earlier.

They will move before the crowd.

The people who wait will still be trying to make the old process feel fair while the system quietly routes around them.

Damn.

Do not wait.

A better job-search strategy

Here is the practical version.

If you are looking for work right now, stop treating the job search like a once-a-week emotional ritual.

Treat it like a system.

Track fresh postings daily.
Prioritize roles posted recently.
Apply while the listing still has energy.
Use AI to tailor context, not invent experience.
Keep a human in the loop for consent and judgment.
Save your career data in a structured way.
Follow up while the role is still active.
Learn from which versions of your profile get traction.
Keep improving the system.

That is the new play.

Not panic applying.

Not blindly mass applying.

Not spending three hours crafting one perfect application that gets buried under 800 others.

Systematic, contextual, early movement.

That is the edge.

Recency is not everything, but it changes everything

Applying early will not make an unqualified person qualified.

It will not fix a bad résumé.

It will not replace networking.

It will not guarantee an interview.

But it changes the conditions.

It gives your application a better shot at being seen while the role is fresh.

It helps you enter before the flood.

It lets you compete when the recruiter is still forming the mental picture of the candidate pool.

Same résumé.

Different moment.

Different outcome.

That is why timing matters.

That is why automation matters.

That is why job seekers need better tools.

If the hiring side is automated, the applicant side cannot stay manual forever.

That is not cheating.

That is balance.

I’m building tools around this exact problem through Exempliphai and writing more about AI, job search, automation, and the future of work. You can follow more of my work at asaday.co, dev.to/keith_azodeh, and medium.com/@keithazodeh.