Anomaly detection for drone video sensing analytics:

Effective systems combine fast, robust low‑level motion extraction with mid‑ and high‑level learning that models normal scene dynamics and interactions, and they must address the unique challenges introduced by an aerial, moving platform. Drones change the problem in three fundamental ways: the camera is not fixed, objects are often small and seen from oblique angles, and scene appearance changes rapidly with altitude, speed, and viewpoint. These constraints make many techniques developed for static surveillance cameras less effective out of the box and force a hybrid approach that leverages both classical computer vision for real‑time proposals and modern learning methods for semantic anomaly scoring. 

At the lowest level, background subtraction and motion‑based proposals remain valuable because they are computationally inexpensive and provide immediate cues about moving regions. Algorithms such as Gaussian mixture models (MOG variants), pixel‑history methods, and sample‑based background models are useful for generating candidate foreground masks and motion blobs that downstream modules can analyze. Their principal weakness in UAV video is sensitivity to ego‑motion and parallax; without compensation they produce many false positives as the background itself moves relative to the sensor. Because of that, practical pipelines almost always include a stabilization or motion‑compensation stage before applying background models. 

Motion compensation can be as simple as global frame registration using feature matches and homography estimation for near‑planar scenes, or as involved as dense optical flow‑based warping when parallax and depth variation are significant. Once motion proposals are available, they serve two roles: they reduce the search space for heavier models and they provide short‑term motion cues for tracking and association. Tracking and multi‑object association are important because many anomalies are defined by trajectories and interactions rather than by single‑frame appearance: sudden dispersal, counter‑flow in a crowd, loitering, or an object entering a restricted area are temporal phenomena that require consistent identity or motion history. For crowd behavior and multi‑agent anomalies, trajectory‑centric models are the dominant paradigm. Recurrent architectures, social pooling mechanisms, graph neural networks, and attention‑based transformers have all been applied to model interactions among agents and to learn typical motion patterns. These models can detect deviations such as abrupt changes in velocity, unusual relative positions, or coordinated motion that differs from learned norms. The aerial viewpoint complicates trajectory extraction because detections are smaller and occlusions differ from ground cameras, so robust detection and tracklet stitching are prerequisites for reliable interaction modeling. 

At a higher semantic level, unsupervised and self‑supervised deep learning methods are now the state of the art for anomaly scoring when the goal is to detect semantic deviations rather than simply motion. Autoencoders, variational autoencoders, predictive networks that forecast future frames or features, and spatio‑temporal encoders (including 3D CNNs and transformer variants) are used to learn a model of “normal” scene dynamics; anomalies are then flagged by reconstruction or prediction error, or by low likelihood under a learned latent distribution. These approaches are powerful because they can capture complex appearance and motion patterns, but they require representative normal data and careful domain adaptation for aerial contexts. In practice, teams combine fast foreground/motion proposals with a lightweight deep model that scores candidate regions or short clips; this hybrid reduces compute and improves precision by focusing learning‑based scoring on the most relevant pixels. Data considerations are central to any deployment. Because anomalies are rare and varied, the most reliable approach is to collect a substantial corpus of normal aerial footage that matches the intended operational envelope (altitudes, speeds, camera gimbals, lighting, seasons). Synthetic augmentation and simulation can help cover rare events and viewpoint variations, and transfer learning from larger ground‑camera datasets can provide useful priors, but domain shift must be explicitly addressed through fine‑tuning, adversarial domain adaptation, or self‑supervised pretraining on unlabeled aerial video. 

Evaluation should be multi‑faceted: frame‑level and pixel‑level metrics (AUC, precision/recall) are useful for measuring detection quality, while event‑level metrics that consider temporal continuity and false alarm rates per hour are more meaningful for operational use. The most common failure modes are false positives caused by ego‑motion and dynamic backgrounds, and false negatives caused by small object size or occlusion. Mitigations include better motion compensation, multi‑scale detection, temporal aggregation of scores, and conservative post‑processing that fuses motion, appearance, and track consistency. 

From an engineering perspective, a recommended pipeline for adding custom models to a drone video sensing analytics repository is sequential: first stabilize or compensate for camera motion; second, run a fast background subtraction or motion saliency stage to produce candidate regions; third, perform detection and short‑term tracking to produce tracklets and trajectories; fourth, apply a learned anomaly scorer that operates on either the candidate region, the tracklet history, or a short clip; and finally fuse scores across modalities and time to produce robust alerts. Lightweight autoencoders or small spatio‑temporal transformers are good starting points for the learned scorer because they balance expressivity and deployability on edge hardware. Operational constraints—compute, latency, and bandwidth—often dictate that heavy models run offboard while simpler motion‑based filters run on the drone. 

There are practical tradeoffs: classical methods are fast and interpretable but brittle under camera motion; deep methods are expressive but data‑hungry and sensitive to domain shift. Combining them yields the best practical performance for UAV analytics. 

Finally, code samples to help implement the hybrid approach is in the references. This includes a short OpenCV example showing MOG2 background subtraction for motion proposals, a minimal PyTorch autoencoder inference pattern where reconstruction error becomes an anomaly score, and a sketch of motion compensation using optical flow to warp frames before background modeling. These sketches are intended as starting points for integration and experimentation rather than production‑ready modules; they demonstrate how to connect fast foreground extraction to a learned anomaly scorer and how to incorporate motion compensation to reduce false alarms. 

Together, these findings form a coherent, implementable strategy for anomaly detection in drone video sensing analytics: stabilize and propose with classical vision, model semantics and interactions with learning, collect representative normal data, and evaluate with both frame‑level and event‑level metrics while explicitly addressing domain shift and operational constraints.  

References: 

1. https://github.com/ravibeta/dvsa-api

2. Previous articles 

3. Sample 1: OpenCV MOG2 background subtraction (motion proposals)

import cv2

cap = cv2.VideoCapture('uav_video.mp4')

bg = cv2.createBackgroundSubtractorMOG2(history=500, varThreshold=16, detectShadows=True)

while True:

    ret, frame = cap.read()

    if not ret: break

    fg = bg.apply(frame)

    _, fg = cv2.threshold(fg, 200, 255, cv2.THRESH_BINARY)

    # optional morphological cleanup

    print(fg.sum()) # simple motion cue

4. Sample 2: Simple PyTorch convolutional autoencoder for frame anomaly scoring

# encoder/decoder omitted for brevity; train on normal frames

# inference: reconstruction error -> anomaly score 

recon = model(frame_tensor)

score = ((frame_tensor - recon)**2).mean().item()

5. Sample 3: Motion compensation sketch using optical flow for background subtraction

# compute flow between frames, warp previous background model, then apply MOG2

flow = cv2.calcOpticalFlowFarneback(prev_gray, gray, None, 0.5,3,15,3,5,1.2,0)

# warp prev frame by flow (implementation detail) then update bg model

 Authenticity in the age of artificial intelligence is no longer a simple question of whether something was produced by a person or by a machine. It is becoming a question of agency, transparency, context, and intent. As generative systems increasingly assist with writing, image creation, speech, decision support, and interpersonal communication, the boundary between human expression and machine-mediated expression has become technically and socially ambiguous. A message may originate from a human idea but be refined by an algorithm; an image may depict a real event but be enhanced, compressed, or reconstructed by software; a profile, résumé, or professional statement may be truthful in substance while optimized in tone by an automated assistant. In this environment, authenticity should not be defined solely by the absence of automation. A more useful standard is whether the final artifact remains meaningfully connected to the human judgment, values, and accountability behind it.

From a technical perspective, AI challenges authenticity because it separates surface form from originating effort. Earlier digital tools changed how people edited, distributed, and formatted communication, but they did not usually generate the substance of expression at scale. Contemporary AI systems can produce fluent language, realistic media, and persuasive interaction patterns with minimal prompting. This creates a verification problem: the observable output may no longer reveal the process that produced it. A polished response may reflect careful human thought, automated pattern completion, or a hybrid of both. The same ambiguity applies to images, audio, video, and synthetic personas. As a result, audiences increasingly need process signals rather than relying only on content signals. Metadata, provenance standards, disclosure norms, and audit trails become important not because every automated contribution is deceptive, but because trust depends on understanding the relationship between representation and reality.

The professional risk is not that AI assistance exists, but that it can obscure responsibility. In business, education, research, design, and public communication, authenticity has traditionally carried an assumption of accountable authorship. Readers, customers, colleagues, and institutions evaluate not only what is said, but who stands behind it and how it was produced. When AI-generated or AI-shaped content is presented without appropriate context, accountability can become diffuse. A leader may appear more empathetic than their actual engagement supports. A candidate may seem more articulate than their underlying competence demonstrates. A brand may sound personal while operating through automated segmentation. These examples do not make AI inherently inauthentic; they show that authenticity depends on whether the use of AI amplifies genuine intention or substitutes for it in a way that misleads the audience.

A strong authenticity framework should therefore distinguish between assistance, augmentation, simulation, and deception. Assistance occurs when AI helps improve clarity, accessibility, translation, structure, or recall while the human remains the source of intent and final judgment. Augmentation occurs when AI expands a person’s expressive range, enabling communication that might otherwise be limited by language barriers, cognitive load, disability, time pressure, or lack of specialized production skills. Simulation occurs when AI creates the appearance of human presence, personality, expertise, or experience without the corresponding human basis. Deception occurs when that simulation is deliberately or negligently presented as something it is not. These categories are more practical than a binary distinction between human-made and machine-made content, because real workflows increasingly involve mixtures of human and computational contribution.

For organizations, the technical challenge is to design systems that preserve human agency rather than merely optimize engagement. Many AI tools are tuned to produce outputs that attract attention, increase response rates, or conform to statistically successful patterns. Those goals can be useful, but they can also flatten individuality and encourage formulaic communication. When optimization becomes the dominant design objective, authenticity erodes because people begin to communicate in the style most likely to perform well rather than in the style that best reflects their actual judgment. Responsible implementation requires explicit choices about when optimization is appropriate, when disclosure is necessary, and when human review is mandatory. It also requires recognizing that measurable engagement is not the same as trust, understanding, or meaningful connection.

Authenticity in 2025 should be treated as a socio-technical property rather than a nostalgic preference for unassisted creation. It emerges when people understand the role of AI in a communication, when the output remains aligned with the human values and decisions behind it, and when accountability is not hidden behind automation. The most credible future is not one in which AI is excluded from expression, but one in which AI is used with disciplined transparency and human control. A technically mature definition of being real must account for hybrid authorship while still protecting trust. In practice, this means that the question is not simply whether AI was used. The better question is whether the human remained meaningfully present in the choices, commitments, and consequences carried by the final work.

References: 

1. “AI & Authenticity: What Does It Mean to Be ‘Real’ in 2025?” written by Ben Szuhaj at Kungfu.ai in 2025

#codingexercise: CodingExercise-07-09-2026.docx

 

DVSA  retention schedule

Retention schedule template (concise, operational): retain each record type only as long as necessary for the stated purpose and to meet legal or contractual obligations; document the legal basis and review date for each entry.

 

Training datasets (raw labeled images used to train models):

purpose—model development and improvement;

retention—retain for up to 3 years unless a shorter business justification applies; controls—hashed identifiers, access limited to ML engineers, versioned snapshots, and deletion workflow that removes source files and associated embeddings.

 

Raw flight video and full-resolution frames:

purpose—safety investigations and mission replay;

retention—retain for 90 days by default; extend to 1–7 years only when required by contract, insurance, or sector rules;

controls—tiered storage, encrypted at rest, and legal‑hold flagging.

 

Promoted catalog records (indexed frames, object metadata, embeddings):

purpose—analytics, search, and copilot responses;

retention—retain 1–5 years depending on reuse value and regulatory needs;

controls—immutable audit log of promotions, ability to redact or unlink personal identifiers, and periodic re‑evaluation.

 

System logs and audit trails (access logs, model versioning, tamper‑evident traces): purpose—security, compliance, and incident response;

retention—retain 1–7 years per enterprise risk policy;

controls—WORM storage, cryptographic integrity checks, and exportable audit packages.

 

Deletion and propagation: when erasure is requested, remove primary records and propagate deletions to indexes, vector stores, backups, and third‑party processors within a documented SLA; provide deletion confirmation and a verifiable deletion receipt.

 

Notes: Retention enforcement is automated, a searchable data inventory is maintained, retention clauses are included in vendor contracts, and all retention and deletion actions are logged for auditability.

 

User‑facing privacy notice (U.S. tailored, plain language):

we collect video, telemetry (GPS, timestamps), derived object metadata, and analytics outputs to provide drone sensing, mapping, and analytics services;

we may use selected data to improve models unless you opt out;

we retain raw flight video for 90 days by default and promoted catalog records for up to 3 years unless law or contract requires otherwise;

you may request access, correction, or deletion of personal data via [support channel], and deletion requests will be executed and propagated within our documented SLA;

we will honor lawful requests and preserve records under legal hold when required by law or litigation.

For enterprise customers we offer contractual controls (DPA, SOC 2, encryption, and no‑training options) and will comply with sectoral retention rules (e.g., financial, healthcare) that may require longer retention.

 

Disclosure: Prompts, responses, and logs can be subject to legal preservation in investigations; AI logs are treated as enterprise records and legal‑hold processes are applied when needed.

 Using DroneNLP/dataset with dvsa-api

The DroneNLP dataset provides a strong foundation for rising up the operatiors stack with safety, and forensic analysis. It is a curated collection of drone flight log messages that includes raw, cleansed, and annotated data, along with task-specific splits for problem identification and event recognition. In practical terms, this means the dataset can support models that classify whether a flight log indicates a problem, identify what kind of problem is present, detect events in a flight timeline, and label those events in a structured way. The broader DroneNLP ecosystem also includes related tools such as DFLER, a drone flight log entity recognizer for components, parameters, functions, actions, issues, and states; ADFLER, which supports automated drone flight log event recognition; and LogNexus, which extracts meaningful sentences from noisy logs. Together, these assets create a transparent data preparation and modeling pipeline that moves from raw drone logs to processed, annotated, and operationally useful intelligence.

Although the dvsa-api repository is not directly indexed here, it can reasonably be treated as a programmable interface to DVSA-related data, such as vehicle records, test outcomes, defects, incidents, and transport safety events. Under that assumption, the integration opportunity is to use dvsa-api as a controlled service or library that exposes structured safety data while DroneNLP contributes the unstructured and semi-structured intelligence extracted from drone flight logs. The result is a realistic technical foundation for connecting drone operational evidence with broader safety, inspection, and compliance records.

Cross-modal safety intelligence is the first choice for use cases. DroneNLP can identify problems, entities, anomalies, and events in flight logs, while dvsa-api can provide structured records about vehicles, defects, test outcomes, and incident histories. Combining these sources would make it possible to build richer risk and incident models than either dataset could support alone. A drone log might reveal repeated GPS drift, battery degradation, sensor anomalies, or loss-of-control events, while DVSA records might show related patterns of vehicle defects, operational failures, or inspection outcomes. When these signals are linked across time, location, operator, and asset type, they can support stronger incident reconstruction, more proactive safety management, and better compliance planning.

One could position the combined system as an operational flight planning assistant rather than merely an analytics backend. The inspiration is similar to ForeFlight in aviation, where weather, navigation, route planning, compliance checks, and pilot workflow are integrated into a single trusted environment. In the drone context, DroneNLP and dvsa-api could be combined to create a workflow-native planning layer for drone and fleet operators. Instead of using log analysis only after incidents occur, the system would use historical log intelligence, current operational data, and structured safety records to help operators plan safer and more efficient missions before takeoff.

Such a Drone Operations Planning Assistant would begin with pre-flight risk assessment. Historical DroneNLP logs could be analyzed for recurring issues such as GPS drift in particular zones, repeated battery constraints, or sensor anomalies under certain operating conditions. DVSA-api data could then contribute structured safety context, such as defect patterns, inspection histories, or location-linked operational risk. These signals could be fused into a consolidated risk score that operators can review before launching a mission. The same platform could also support route optimization by identifying critical coverage areas, accounting for log-derived constraints such as battery limits or sensor reliability, and recommending flight paths that balance coverage, safety, and mission objectives.

Continuity planning would be another important capability. DroneNLP event recognition can detect gaps, interruptions, or incomplete mission segments in prior logs, while dvsa-api or related geospatial services can help index affected locations and mission areas. The assistant could recommend re-flight segments, overlapping passes, or additional inspection coverage where prior evidence is weak. This would make the system more than a reporting tool; it would become a mission continuity layer that helps operators understand what has already been covered, where uncertainty remains, and how to complete the operational picture.

The architecture for this use case can be described as a sequence of connected layers. A data ingestion layer would collect historical and real-time DroneNLP logs together with DVSA-api records, video streams, geospatial indexes, or other operational data. An analysis layer would run DroneNLP models to extract anomalies, components, issues, and constraints, while dvsa-api services would compute or retrieve structured safety and compliance signals. A fusion layer would align log-derived constraints with geospatial and structured safety data to produce consolidated risk and coverage maps. A planning layer would use those maps to support route optimization, continuity planning, and risk-aware mission recommendations. Finally, an interface layer would present the results in operator-native language, using concepts such as coverage gaps, risk zones, mission continuity, and human-in-the-loop overrides rather than purely technical model outputs.

The underlying schema could center on a small number of reusable entities. A Drone Log Event would capture timestamp, component, anomaly type, issue type, and severity. A Video Anomaly or geospatial observation would capture frame or segment identifiers, coordinates, anomaly type, and confidence. A Risk Zone would represent a geospatial area with a risk score and a source signal, whether from logs, video, DVSA records, or a combination of sources. A Flight Plan would contain route segments, coverage score, risk score, and continuity flags. These entities would be connected through relationships that map drone events to risk zones, geospatial observations to risk zones, and flight plans to the risks and constraints they must account for. This structure would make the system extensible while preserving explainability.

A second promising direction is a forensic correlation engine for incidents. DroneNLP already has a natural forensic orientation because it can extract entities, identify events, and reconstruct timelines from messy operational logs. When paired with dvsa-api, this capability could help investigators connect drone incidents with related vehicle records, test results, defects, and safety events. The system would ingest a drone incident case, retrieve relevant DVSA records for the appropriate time, location, operator, or asset, enrich the drone logs using DFLER and event recognition models, and then apply temporal, spatial, and semantic correlation logic. Temporal alignment would identify events that occurred within relevant time windows. Spatial alignment would connect incidents or observations that occurred within proximity thresholds. Semantic alignment would use an ontology to relate differently worded but conceptually similar issues, such as a deceleration anomaly and a braking-related defect.

The forensic interface could present a combined timeline of drone events and DVSA records, an entity graph linking drones, vehicles, operators, locations, issues, and components, and an evidence summary that explains why the system believes certain events are related. This would be useful for regulators, insurers, safety teams, and operators because it would reduce the manual burden of reconstructing complex multi-asset incidents. It also creates a strong research agenda around explainable AI in safety investigations. The system should be careful not to overstate causality, however. Correlations should be presented with uncertainty, confidence levels, and supporting evidence so that investigators can make informed judgments rather than accepting automated conclusions uncritically.

The modeling approach for risk scoring could include time-series methods, survival analysis, hazard models, graph-based models, or embedding-based fusion. Drone logs could be represented as text embeddings or structured event sequences, while DVSA records could be represented as structured embeddings derived from defects, outcomes, and asset histories. A joint model could then learn patterns that predict elevated risk. This direction has clear operational value because it shifts the platform from reactive analysis to proactive safety management. It also offers a strong research angle in multi-source risk modeling and can be evaluated quantitatively using historical data. The main limitations are the need for sufficient historical data, careful handling of overfitting, and responsible communication of risk scores so that users understand uncertainty and do not treat scores as deterministic judgments.

Maintenance and compliance analytics provide another practical extension. DroneNLP can infer maintenance needs from flight logs by identifying recurring issues, affected components, and abnormal states. These signals can be compared with DVSA defect categories and inspection outcomes to build a cross-domain defect taxonomy. For example, a drone motor overheating pattern might be mapped to a broader powertrain or propulsion-related defect category, while repeated GPS or sensor issues might be mapped to reliability or control-system concerns. Once this taxonomy exists, the system could recommend maintenance actions, track whether those actions are performed, and measure whether they reduce recurrence. It could also compute maintenance effectiveness, defect recurrence patterns, and mean time between defects.

This maintenance-oriented approach would bridge drone operations with established inspection and compliance practices. It would also fit naturally into observability dashboards because the outputs are operationally meaningful: recurring defects, maintenance recommendations, compliance status, and post-intervention improvement. The principal challenge is that mapping between drone issues and DVSA-style defect categories may be partly subjective, and drone-side maintenance data may be sparse or inconsistent. Even so, the approach is valuable because it creates a practical pathway from raw log intelligence to maintenance planning and compliance improvement.

A final research-oriented direction is to use DVSA data as an external benchmark for DroneNLP models. The central question is whether DroneNLP’s event and problem labels are consistent with broader safety patterns found in structured inspection, defect, or incident records. For example, if certain regions or operators show elevated defect rates in DVSA data, researchers could examine whether DroneNLP models also detect more frequent or severe drone log issues in corresponding contexts. This would not prove causality, but it could support cross-domain consistency checks and help validate whether the models capture meaningful safety signals.

The benchmarking framework could also support robustness testing and transfer learning. Synthetic noise or domain shifts could be introduced into drone logs to evaluate how well DroneNLP models maintain performance, especially when augmented with contextual signals from DVSA records. If DVSA defect descriptions include textual data, they could also be used to pretrain or augment models for safety-related language understanding. Evaluation scripts would pull DVSA data for selected cohorts, run DroneNLP models on corresponding logs, and compute cross-domain metrics such as correlation, mutual information, or consistency between predicted problems and observed safety outcomes. This direction is especially well suited for academic publishing because it strengthens the scientific rigor of DroneNLP work and frames the integration as a broader contribution to multi-domain validation of safety NLP systems.

Among these proposals, the highest-priority path is to begin with the operational flight planning assistant because it aligns strongly with observability, inflection detection, importance sampling, and operator-facing decision support. It also creates a broad platform on which the other ideas can build. Once the planning assistant can ingest logs, retrieve structured safety data, identify risk zones, and support route or mission decisions, the same data foundation can support forensic correlation and predictive risk scoring. The forensic engine would add investigative depth, while predictive scoring would extend the system toward proactive safety management. Maintenance and compliance analytics, along with benchmarking and evaluation, can then become complementary modules or follow-on research projects.

The strategic value of this integration is that it moves dvsa-api from being a data access layer into becoming part of an operational intelligence platform. DroneNLP contributes domain-specific textual intelligence from flight logs; dvsa-api contributes structured safety, inspection, and incident context; and the combined system can support planning, investigation, prediction, maintenance, and evaluation. The strongest narrative is not simply that two datasets can be joined, but that unstructured drone operational experience can be converted into actionable safety intelligence when fused with structured regulatory and inspection data. This positions the platform as operator-empowering AI: practical, workflow-native, explainable, and grounded in real safety evidence.

 Sample mail campaign

// ── CONFIG ────────────────────────────────────────────────────────────────

const SHEET_NAME = "Contacts";

const DAILY_LIMIT = 500; // ← Change to 1500 if you have Google Workspace

const FROM_NAME = "Ravi Rajamani";

// Column indices (1-based, matching your sheet layout)

const COL_EMAIL = 1; // Column A: to_email

const COL_SUBJECT = 7; // Column G: subject

const COL_BODY = 8; // Column H: body

const COL_STATUS = 9; // Column I: Status

// ── MAIN FUNCTION ─────────────────────────────────────────────────────────

function sendCampaign() {

  const ss = SpreadsheetApp.getActiveSpreadsheet();

  const sheet = ss.getSheetByName(SHEET_NAME);

  if (!sheet) {

    Logger.log('ERROR: Sheet "' + SHEET_NAME + '" not found. Check the tab name.');

    return;

  }

  const lastRow = sheet.getLastRow();

  if (lastRow < 2) {

    Logger.log("No data rows found.");

    return;

  }

  // ── READ ALL DATA IN ONE CALL (the key fix) ───────────────────────────

  // This fetches the entire sheet as a 2D array in a single API call,

  // instead of making 4 individual calls per row inside the loop.

  const numRows = lastRow - 1; // exclude header row

  const allData = sheet.getRange(2, 1, numRows, COL_STATUS).getValues();

  // allData[i] is a 0-indexed array for row (i+2) of the sheet

  // allData[i][0] = to_email, [6] = subject, [7] = body, [8] = Status

  Logger.log("Data loaded. Total rows: " + numRows);

  // ── COLLECT ROWS TO SEND ──────────────────────────────────────────────

  // Build a list of {sheetRow, email, subject, body} for unsent rows only.

  // This entire pass is pure in-memory — no Sheets API calls.

  const toSend = [];

  for (let i = 0; i < allData.length; i++) {

    const status = String(allData[i][COL_STATUS - 1]).trim();

    if (status === "Sent") continue; // already sent

    if (status.startsWith("Error:")) continue; // skip permanent errors

    const email = String(allData[i][COL_EMAIL - 1]).trim();

    const subject = String(allData[i][COL_SUBJECT - 1]).trim();

    const body = String(allData[i][COL_BODY - 1]).trim();

    if (!email || !email.includes("@")) continue; // bad address

    if (!subject || !body) continue; // incomplete row

    toSend.push({ sheetRow: i + 2, email, subject, body }); // sheetRow is 1-based

  }

  Logger.log("Unsent rows found: " + toSend.length);

  if (toSend.length === 0) {

    Logger.log("Campaign complete — all rows have been sent.");

    return;

  }

  // ── SEND EMAILS ───────────────────────────────────────────────────────

  // Batch status updates: collect changes, then write them all at once

  // at the end of the run (or every 50 sends as a safety checkpoint).

  let sentThisRun = 0;

  let errorCount = 0;

  const statusUpdates = []; // {sheetRow, value}

  const limit = Math.min(DAILY_LIMIT, toSend.length);

  for (let j = 0; j < limit; j++) {

    const { sheetRow, email, subject, body } = toSend[j];

    try {

      MailApp.sendEmail({

        to: email,

        subject: subject,

        body: body,

        name: FROM_NAME

      });

      statusUpdates.push({ sheetRow, value: "Sent" });

      sentThisRun++;

      if (sentThisRun % 50 === 0) {

        // Checkpoint write every 50 sends so progress isn't lost if we time out

        flushStatusUpdates(sheet, statusUpdates);

        Logger.log("Checkpoint: " + sentThisRun + " sent so far...");

      }

    } catch (e) {

      statusUpdates.push({ sheetRow, value: "Error: " + e.message });

      errorCount++;

      Logger.log("FAILED row " + sheetRow + " (" + email + "): " + e.message);

    }

    // 200ms pause to stay within Gmail's per-second rate limit

    Utilities.sleep(200);

  }

  // ── FINAL WRITE ───────────────────────────────────────────────────────

  // Write any remaining status updates not yet flushed

  flushStatusUpdates(sheet, statusUpdates);

  // ── SUMMARY ───────────────────────────────────────────────────────────

  Logger.log("─────────────────────────────────────");

  Logger.log("Run complete.");

  Logger.log("Sent this run: " + sentThisRun);

  Logger.log("Errors this run: " + errorCount);

  Logger.log("Remaining: " + (toSend.length - sentThisRun));

  Logger.log("─────────────────────────────────────");

}

// ── HELPER: batch-write all pending status updates ─────────────────────────

// Clears the array after writing so we don't double-write on checkpoints.

function flushStatusUpdates(sheet, updates) {

  if (updates.length === 0) return;

  for (const { sheetRow, value } of updates) {

    sheet.getRange(sheetRow, COL_STATUS).setValue(value);

  }

  SpreadsheetApp.flush(); // force Sheets to commit writes immediately

  updates.length = 0; // clear in-place so the caller's array is emptied

}

MCP

 A Multi‑agent Control Plane aka MCP and the Model‑Context‑Protocol from Anthropic als aka MCP, represent two complementary but fundamentally different ways of organizing intelligence inside complex autonomous systems. In drone video sensing pipelines such as a dvsa‑api architecture, both patterns appear naturally because the system must coordinate multiple decision‑making components while also ensuring that each model invocation is grounded in the correct operational context. Although they often coexist, they solve different problems: the control plane governs *how* agents collaborate to achieve a mission, while the protocol governs *how* each model call is structured, contextualized, and made reliable.

A multi‑agent control plane is a supervisory fabric that orchestrates autonomous components. It defines roles, responsibilities, communication rules, and escalation paths among agents that may specialize in perception, planning, navigation, anomaly detection, or mission‑level reasoning. In a drone video sensing workflow, one agent may handle frame‑level semantic segmentation, another may track objects across time, another may evaluate inflection signatures in trajectories, and another may decide whether the drone should adjust altitude or camera angle. The control plane ensures that these agents do not behave like isolated microservices but instead operate as a coordinated team with shared state, shared goals, and shared constraints. It manages arbitration when agents disagree, prioritizes safety‑critical signals, and enforces mission‑level policies such as geofencing, battery‑aware routing, or privacy‑preserving video capture. In practice, this means the control plane is responsible for agent lifecycle management, concurrency, delegation, and the routing of tasks to the right agent at the right time. It is the backbone that allows agentic UAV systems to scale from simple single‑drone missions to complex multi‑drone fleets performing collaborative sensing.

The Model‑Context‑Protocol is about ensuring that each model invocation is predictable, auditable, and grounded. It defines how a model is called, what context accompanies the call, and how the output is interpreted. In drone video sensing, this matters because perception models are extremely sensitive to the surrounding metadata: camera intrinsics, GPS coordinates, IMU readings, timestamps, mission parameters, and environmental conditions. A model that receives raw pixels without context may misclassify a vehicle, misjudge depth, or fail to detect an inflection point in a trajectory. The protocol ensures that every model call includes the correct context bundle, that the model’s output is wrapped in a structured schema, and that downstream agents can reliably consume the result. It also enforces versioning, grounding rules, and safety constraints so that the system never invokes a model with stale calibration data or missing geospatial metadata. In short, the protocol governs the *contract* between the model and the rest of the system.

Real‑world UAV use‑cases can explain these differences. In a dvsa‑api pipeline performing live convoy monitoring, the control plane decides which drone should focus on which vehicle, when to hand off tracking responsibilities between agents, and how to fuse observations from multiple drones into a shared semantic map. The Model‑Context‑Protocol ensures that each perception model receives the correct camera pose, timestamp, and mission context so that object detections are consistent across drones. In agricultural monitoring, the control plane coordinates agents that detect crop stress, agents that plan optimal flight paths, and agents that trigger alerts to ground operators. The protocol ensures that the vegetation‑index model receives the correct spectral calibration and environmental metadata. In emergency response, the control plane arbitrates between agents that detect survivors, agents that classify hazards, and agents that plan safe approach routes. The protocol ensures that thermal‑vision models receive the correct sensor context so that detections remain reliable under varying lighting conditions.

Their strengths also differ. A multi‑agent control plane excels at distributed decision‑making, fault tolerance, and mission‑level coordination. It is the architectural mechanism that allows UAVs to behave like autonomous collaborators rather than isolated sensors. The Model‑Context‑Protocol excels at reliability, reproducibility, and correctness of model calls. It prevents silent failures caused by missing metadata, inconsistent schemas, or ambiguous outputs. The control plane is about *behavior*; the protocol is about *grounding*. The control plane scales horizontally across agents; the protocol scales vertically across model invocations. The control plane handles negotiation, delegation, and arbitration; the protocol handles structure, context, and safety.

In drone video sensing systems, both are indispensable. Without a multi‑agent control plane, UAVs cannot coordinate complex missions or integrate multiple forms of intelligence. Without the Model‑Context‑Protocol, perception models become brittle, ungrounded, and unreliable. Together, they form the foundation of modern agentic UAV architectures: one ensures that autonomous agents collaborate effectively, and the other ensures that each model call is contextually correct and operationally safe. Their interplay is what allows dvsa‑api systems to deliver robust inflection detection, importance‑sampled analytics, and real‑time geospatial intelligence across dynamic, uncertain environments.

Implementation: https://gitub.com/ravibeta/dvsa-api/pull/13

 Diante Fuchs’s The Gift of Anxiety: Harnessing the EASE Method to Turn Stuck Anxiety into Your Greatest Ally, published by TCK in 2024, reframes anxiety not as an enemy to defeat but as a natural emotional signal designed to protect, guide, and inform us. Many people experience anxiety as something disruptive or shameful, and their first instinct is often to suppress it, escape it, or eliminate it entirely. Fuchs argues that this response misunderstands anxiety’s purpose. At its best, anxiety is an inner alarm that draws attention to something important and prompts constructive action. The challenge is not the presence of anxiety itself, but the way people respond when anxiety becomes the focus of fear.

Ordinary anxiety can be useful because it directs attention toward preparation and safety. Feeling nervous before an important meeting, for example, may motivate someone to prepare carefully, dress appropriately, plan a route, and arrive on time. Once those actions are taken, the anxiety usually subsides because its message has been received and addressed. In this sense, anxiety can help people navigate uncertainty with greater awareness and responsibility. Problems arise, however, when the alarm does not turn off and begins signaling about itself. This is what Fuchs calls “stuck anxiety”: a cycle in which people become anxious not only about a situation but about the fact that they are anxious. They may begin monitoring physical symptoms such as dizziness, nausea, a racing heart, or tightness in the chest, then interpret those sensations as signs of danger. The result is a loop in which anxiety about anxiety intensifies the original distress.

Stuck anxiety often develops through a recognizable pattern. At first, anxiety lingers longer than expected and produces fear and overwhelm. In response, a person may try urgently to reject or eliminate the feeling through coping strategies, reassurance, or treatment, but the goal of making anxiety disappear can create even greater sensitivity to its return. Over time, this sensitivity becomes hypervigilance, a constant checking for symptoms that can interfere with work, routines, and relationships. Eventually, the person may begin avoiding situations that trigger discomfort. Avoidance brings temporary relief, but it also teaches the brain that the avoided situation is dangerous, reinforcing the belief that the person cannot cope. Fear becomes frustration, frustration becomes fixation, fixation becomes exhaustion, and exhaustion leads to avoidance, which then restarts the cycle.

To break this cycle, Fuchs introduces the EASE method: Empower, Accept, Shift, and Engage. The first step, Empower, begins with understanding what anxiety is doing in the body. When the brain detects a threat, it releases adrenaline and activates the fight-or-flight response. The heart beats faster to move blood to the muscles, breathing quickens to supply more oxygen, digestion slows to conserve energy, and the body releases glucose for strength. Sensations such as shakiness, nausea, dizziness, chest tightness, or a racing heart are not proof that something is wrong; they are signs that the body is preparing to protect itself. Knowledge reduces fear because it transforms these sensations from mysterious threats into understandable survival responses.

Empowerment also means examining the roots of anxiety with curiosity rather than judgment. Fuchs compares anxiety to a plant. Biological factors such as genetics or hormones may be the seed, while environmental experiences provide the soil and present-day stressors provide the water. Painful memories, early patterns of uncertainty, current financial pressure, toxic relationships, or demanding work conditions can all create circumstances in which anxiety grows. By reflecting on these influences, people can better understand what their anxiety is trying to communicate. They can identify whether medical support, lifestyle changes, stronger boundaries, or deeper emotional work may be needed. This process turns anxiety into information rather than an enemy.

The second step, Accept, asks people to give anxiety space instead of pushing it away. Fuchs suggests that anxiety behaves like a frantic visitor at the door: ignoring the visitor or refusing to open the door only makes the knocking louder, while listening calmly allows the visitor to settle. Acceptance does not mean liking anxiety or giving it control. It means recognizing that anxiety is part of human experience and responding to it with compassion. Many people learned early in life that they had to be perfect, controlled, or emotionally composed to feel safe or loved. As adults, they can begin to reassure themselves that mistakes, strong emotions, and uncertainty are manageable. This kind of self-compassion helps soften anxiety’s intensity.

Acceptance also involves challenging the “what if” questions that fuel anxious spirals. Rather than avoiding frightening possibilities, Fuchs encourages asking, “So what if that happens?” and then following the chain of feared outcomes until it becomes clear that even difficult situations are often survivable and manageable. Someone who fears having a panic attack while driving may realize that they could pull over, breathe, call for help if needed, and wait for the sensations to pass. The experience may be uncomfortable, but it is not necessarily dangerous. By testing anxious assumptions against evidence, people can replace catastrophic beliefs with a steadier confidence in their ability to cope.

The third step, Shift, teaches people to redirect attention away from anxious monitoring and back toward the present. This does not require forcing anxiety to disappear. Instead, it involves allowing anxiety to exist while choosing to place attention elsewhere. Grounding practices such as the 5,4,3,2,1 method can help: noticing five things one can see, four things one can touch, three sounds one can hear, two scents one can smell, and one flavor one can taste. By engaging the senses, the mind reconnects with the immediate environment, the rational brain becomes more active, and the nervous system begins to settle.

Shifting also means questioning unhelpful thoughts and reconnecting with personal values. An anxious thought can be treated like an expensive purchase: before accepting it, a person can ask whether believing it is worth the cost. If the thought “I will lose control in public” leads to isolation and lost relationships, it may not be worth buying. Other techniques include mentally canceling the thought like a pop-up window, repeating it in a silly voice to reduce its power, or focusing on the facts of the present moment rather than imagined future disasters. Beyond individual thoughts, anxiety may also reveal a deeper misalignment between the life a person is living and the values that matter most. Someone may feel anxious because they are pursuing a career chosen to satisfy family expectations rather than their own need for creativity, freedom, connection, or growth. Clarifying values and taking steps toward them can restore balance and reduce inner conflict.

The final step, Engage, invites people to move toward what anxiety has taught them to avoid. Avoidance may feel protective in the short term, but over time it strengthens fear and narrows life. Engagement reverses this pattern through small, deliberate actions. The goal is not to wait until anxiety vanishes, but to act while anxiety is present and learn through experience that discomfort can be tolerated. A person who dreads calling the dentist may notice that postponing the appointment prolongs both physical pain and emotional stress. By making the call, scheduling the visit, and following through, they reduce avoidance’s power and build evidence that they can handle difficult tasks.

Fuchs recommends turning engagement into specific, measurable, achievable, relevant, and time-sensitive goals. If someone misses riding a bike but feels anxious about riding alone, the goal might be to ride twice a week for one hour at a time. Such goals are concrete, realistic, and trackable. Each completed action deserves recognition because celebration helps the brain associate facing anxiety with positive outcomes. Over time, these small victories create confidence, self-approval, and momentum. Anxiety loses authority as the person learns to move forward with it rather than organize life around avoiding it.

The power of this approach appears in Fuchs’s example of Nora, a once-confident assistant to a top CEO who lost her job and later succeeded in commercial property sales. Although she was outwardly doing well, she began experiencing morning dread and low motivation. Instead of treating anxiety as a symptom to suppress, Nora listened to what it revealed. She realized that working from home had left her lonely, that harsh self-talk intensified her distress, and that financial pressure made every morning feel threatening. In response, she joined a co-working space, practiced self-compassion, allowed herself restorative breaks and time with friends, and adjusted her finances to reduce pressure. By responding to anxiety with practical changes and emotional care, she created a healthier and more balanced life.

The Gift of Anxiety presents anxiety as a guide to deeper self-understanding. Anxiety points toward old beliefs, unresolved fears, present-day stressors, neglected needs, and avoided responsibilities. When people fight it, monitor it, or flee from it, the alarm grows louder. When they understand it, accept it, shift their attention, and engage with life deliberately, the alarm begins to quiet. Fuchs’s central message is that anxiety is not proof of weakness or failure. It is part of the emotional world, and when approached with knowledge, compassion, and courage, it can become a source of balance, growth, and healing.

 

Authenticity in the age of artificial intelligence is no longer a simple question of whether something was produced by a person or by a machine. It is becoming a question of agency, transparency, context, and intent. As generative systems increasingly assist with writing, image creation, speech, decision support, and interpersonal communication, the boundary between human expression and machine-mediated expression has become technically and socially ambiguous. A message may originate from a human idea but be refined by an algorithm; an image may depict a real event but be enhanced, compressed, or reconstructed by software; a profile, résumé, or professional statement may be truthful in substance while optimized in tone by an automated assistant. In this environment, authenticity should not be defined solely by the absence of automation. A more useful standard is whether the final artifact remains meaningfully connected to the human judgment, values, and accountability behind it.

From a technical perspective, AI challenges authenticity because it separates surface form from originating effort. Earlier digital tools changed how people edited, distributed, and formatted communication, but they did not usually generate the substance of expression at scale. Contemporary AI systems can produce fluent language, realistic media, and persuasive interaction patterns with minimal prompting. This creates a verification problem: the observable output may no longer reveal the process that produced it. A polished response may reflect careful human thought, automated pattern completion, or a hybrid of both. The same ambiguity applies to images, audio, video, and synthetic personas. As a result, audiences increasingly need process signals rather than relying only on content signals. Metadata, provenance standards, disclosure norms, and audit trails become important not because every automated contribution is deceptive, but because trust depends on understanding the relationship between representation and reality.

The professional risk is not that AI assistance exists, but that it can obscure responsibility. In business, education, research, design, and public communication, authenticity has traditionally carried an assumption of accountable authorship. Readers, customers, colleagues, and institutions evaluate not only what is said, but who stands behind it and how it was produced. When AI-generated or AI-shaped content is presented without appropriate context, accountability can become diffuse. A leader may appear more empathetic than their actual engagement supports. A candidate may seem more articulate than their underlying competence demonstrates. A brand may sound personal while operating through automated segmentation. These examples do not make AI inherently inauthentic; they show that authenticity depends on whether the use of AI amplifies genuine intention or substitutes for it in a way that misleads the audience.

A strong authenticity framework should therefore distinguish between assistance, augmentation, simulation, and deception. Assistance occurs when AI helps improve clarity, accessibility, translation, structure, or recall while the human remains the source of intent and final judgment. Augmentation occurs when AI expands a person’s expressive range, enabling communication that might otherwise be limited by language barriers, cognitive load, disability, time pressure, or lack of specialized production skills. Simulation occurs when AI creates the appearance of human presence, personality, expertise, or experience without the corresponding human basis. Deception occurs when that simulation is deliberately or negligently presented as something it is not. These categories are more practical than a binary distinction between human-made and machine-made content, because real workflows increasingly involve mixtures of human and computational contribution.

For organizations, the technical challenge is to design systems that preserve human agency rather than merely optimize engagement. Many AI tools are tuned to produce outputs that attract attention, increase response rates, or conform to statistically successful patterns. Those goals can be useful, but they can also flatten individuality and encourage formulaic communication. When optimization becomes the dominant design objective, authenticity erodes because people begin to communicate in the style most likely to perform well rather than in the style that best reflects their actual judgment. Responsible implementation requires explicit choices about when optimization is appropriate, when disclosure is necessary, and when human review is mandatory. It also requires recognizing that measurable engagement is not the same as trust, understanding, or meaningful connection.

Authenticity in 2025 should be treated as a socio-technical property rather than a nostalgic preference for unassisted creation. It emerges when people understand the role of AI in a communication, when the output remains aligned with the human values and decisions behind it, and when accountability is not hidden behind automation. The most credible future is not one in which AI is excluded from expression, but one in which AI is used with disciplined transparency and human control. A technically mature definition of being real must account for hybrid authorship while still protecting trust. In practice, this means that the question is not simply whether AI was used. The better question is whether the human remained meaningfully present in the choices, commitments, and consequences carried by the final work.

References:“AI & Authenticity: What Does It Mean to Be ‘Real’ in 2025?” written by Ben Szuhaj at Kungfu.ai in 2025

2.    

 How to integrate reasoning models into dvsa-api

Integrate reasoning models into dvsa-api by adding a modular inference layer that routes requests to Azure Foundry/OpenAI reasoning deployments or to a hosted custom reasoning model via a lightweight orchestration policy, expose a unified prompt-and-observation interface in the API, and instrument token-level, provenance, and cost telemetry for safe production use.

The integration should treat reasoning models as first-class, stateful inference engines that produce both reasoning traces and final completions. Reasoning models improve complex decisioning, multi-step scene interpretation, and auditability because they explicitly generate internal reasoning tokens and verification steps; Azure Foundry and Azure OpenAI expose reasoning-specific controls (reasoning_effort, reasoning_tokens) and developer messages to tune effort and provenance. 

Start by adding a Reasoning Adapter inside dvsa-api that normalizes inputs (multi-frame metadata, object tracks, sensor confidence) into a compact context window and supports two modes: (1) explainable inference that returns reasoning traces for human review, and (2) actionable inference that emits structured actions (labels, bounding boxes, confidence, remediation steps). This mirrors ReAct-style interleaving of reasoning and actions to allow the model to query retrieval indices or call deterministic vision pipelines when needed. 

Operational design must include a model-orchestration policy that routes requests by cost, latency, and privacy: low-latency or PII-sensitive queries go to on-prem/custom models; high-complexity reasoning goes to Azure reasoning deployments; fallback rules and canary routing enable safe rollouts. Log model version, token counts, retrieval snapshot IDs, and reasoning_effort for every call to support audit and chargeback. 

Productionize with MLOps best practices: containerize custom reasoning models, expose a gRPC/REST inference shim, implement feature-store parity for any precomputed features, and add continuous monitoring for data drift, hallucination rates, and latency SLAs. Use shadow deployments and A/B canaries to validate reasoning trace quality against human labels before full rollout. 

Architectural trade-offs are straightforward: Azure reasoning models give superior out-of-the-box chain-of-thought and managed scaling but incur cloud cost and data residency constraints; custom models offer privacy and lower marginal cost at scale but require investment in quantization, inference optimization, and safety filters. A hybrid orchestration yields the best ROI for dvsa-api workflows that mix sensitive telemetry and high-complexity reasoning. 

Implementation roadmap: add the Reasoning Adapter and orchestration policy, wire Azure SDK clients and a pluggable custom-model shim, implement token- and trace-level telemetry, run a 4-week canary with shadow logging, then enable human-in-the-loop review for high-risk outputs. Key metrics to track: reasoning_tokens per request, hallucination incidents, latency P95, and model selection cost per inference.

Bulk mailer for mail campaigns

 // ── CONFIG ────────────────────────────────────────────────────────────────

const SHEET_NAME = "Contacts";

const DAILY_LIMIT = 500; // ← Change to 2000 if you have Google Workspace

const FROM_NAME = "Ravi Rajamani";

// Column indices (1-based, matching your sheet layout)

const COL_EMAIL = 1; // Column A: to_email

const COL_SUBJECT = 7; // Column G: subject

const COL_BODY = 8; // Column H: body

const COL_STATUS = 9; // Column I: Status

// ── MAIN FUNCTION ─────────────────────────────────────────────────────────

function sendCampaign() {

  const ss = SpreadsheetApp.getActiveSpreadsheet();

  const sheet = ss.getSheetByName(SHEET_NAME);

  if (!sheet) {

    Logger.log('ERROR: Sheet "' + SHEET_NAME + '" not found. Check the tab name.');

    return;

  }

  const lastRow = sheet.getLastRow();

  if (lastRow < 2) {

    Logger.log("No data rows found.");

    return;

  }

  // ── READ ALL DATA IN ONE CALL (the key fix) ───────────────────────────

  // This fetches the entire sheet as a 2D array in a single API call,

  // instead of making 4 individual calls per row inside the loop.

  const numRows = lastRow - 1; // exclude header row

  const allData = sheet.getRange(2, 1, numRows, COL_STATUS).getValues();

  // allData[i] is a 0-indexed array for row (i+2) of the sheet

  // allData[i][0] = to_email, [6] = subject, [7] = body, [8] = Status

  Logger.log("Data loaded. Total rows: " + numRows);

  // ── COLLECT ROWS TO SEND ──────────────────────────────────────────────

  // Build a list of {sheetRow, email, subject, body} for unsent rows only.

  // This entire pass is pure in-memory — no Sheets API calls.

  const toSend = [];

  for (let i = 0; i < allData.length; i++) {

    const status = String(allData[i][COL_STATUS - 1]).trim();

    if (status === "Sent") continue; // already sent

    if (status.startsWith("Error:")) continue; // skip permanent errors

    const email = String(allData[i][COL_EMAIL - 1]).trim();

    const subject = String(allData[i][COL_SUBJECT - 1]).trim();

    const body = String(allData[i][COL_BODY - 1]).trim();

    if (!email || !email.includes("@")) continue; // bad address

    if (!subject || !body) continue; // incomplete row

    toSend.push({ sheetRow: i + 2, email, subject, body }); // sheetRow is 1-based

  }

  Logger.log("Unsent rows found: " + toSend.length);

  if (toSend.length === 0) {

    Logger.log("Campaign complete — all rows have been sent.");

    return;

  }

  // ── SEND EMAILS ───────────────────────────────────────────────────────

  // Batch status updates: collect changes, then write them all at once

  // at the end of the run (or every 50 sends as a safety checkpoint).

  let sentThisRun = 0;

  let errorCount = 0;

  const statusUpdates = []; // {sheetRow, value}

  const limit = Math.min(DAILY_LIMIT, toSend.length);

  for (let j = 0; j < limit; j++) {

    const { sheetRow, email, subject, body } = toSend[j];

    try {

      MailApp.sendEmail({

        to: email,

        subject: subject,

        body: body,

        name: FROM_NAME

      });

      statusUpdates.push({ sheetRow, value: "Sent" });

      sentThisRun++;

      if (sentThisRun % 50 === 0) {

        // Checkpoint write every 50 sends so progress isn't lost if we time out

        flushStatusUpdates(sheet, statusUpdates);

        Logger.log("Checkpoint: " + sentThisRun + " sent so far...");

      }

    } catch (e) {

      statusUpdates.push({ sheetRow, value: "Error: " + e.message });

      errorCount++;

      Logger.log("FAILED row " + sheetRow + " (" + email + "): " + e.message);

    }

    // 200ms pause to stay within Gmail's per-second rate limit

    Utilities.sleep(200);

  }

  // ── FINAL WRITE ───────────────────────────────────────────────────────

  // Write any remaining status updates not yet flushed

  flushStatusUpdates(sheet, statusUpdates);

  // ── SUMMARY ───────────────────────────────────────────────────────────

  Logger.log("─────────────────────────────────────");

  Logger.log("Run complete.");

  Logger.log("Sent this run: " + sentThisRun);

  Logger.log("Errors this run: " + errorCount);

  Logger.log("Remaining: " + (toSend.length - sentThisRun));

  Logger.log("─────────────────────────────────────");

}

// ── HELPER: batch-write all pending status updates ─────────────────────────

// Clears the array after writing so we don't double-write on checkpoints.

function flushStatusUpdates(sheet, updates) {

  if (updates.length === 0) return;

  for (const { sheetRow, value } of updates) {

    sheet.getRange(sheetRow, COL_STATUS).setValue(value);

  }

  SpreadsheetApp.flush(); // force Sheets to commit writes immediately

  updates.length = 0; // clear in-place so the caller's array is emptied

}

 Understanding Perplexity’s “Computer” mode of execution for my drone video sensing applications:

When Perplexity introduced Computer, they described it as a digital worker capable of using “your computer to complete tasks for you.” Their public documentation and product pages emphasize that Computer can operate across desktop, mobile, Slack, and Microsoft 365, and that it can perform long running workflows such as research, document creation, email coordination, and scheduled jobs. The phrasing “uses your computer” naturally raises the question: does Perplexity install a local agent on the end user’s machine, similar to how Azure installs the Azure VM Agent or AWS installs the EC2 SSM Agent to gain visibility and control over compute resources?

Perplexity does not describe installing a privileged system level agent like Azure’s or AWS’s cloud management agents. Instead, their “uses your computer” capability appears to rely on a local execution harness embedded in the Perplexity desktop app, browser extension, or integration client. This harness exposes a controlled interface that the cloud hosted Computer agent can command. In other words, Perplexity does not install a daemon with OS level privileges; rather, it installs a client side sandbox that can perform user authorized actions such as opening tabs, filling forms, interacting with files the user selects, or automating workflows inside the boundaries of the app’s permissions.

This model is consistent with how Perplexity describes Computer’s security posture: tasks run in isolated environments, actions require explicit user permission, and the system is designed to avoid privileged access. It is also consistent with the fact that Computer runs identically on mobile, desktop, Slack, and Microsoft 365, which strongly suggests a portable client side execution layer rather than a deep OS level agent. The cloud agent plans and orchestrates tasks, but the actual execution on the user’s machine is mediated through the Perplexity client, which acts as a bridge between cloud intelligence and local capabilities.

The transition between cloud execution and local execution therefore follows a predictable pattern. The user issues a high level goal in the Perplexity interface. The cloud hosted Computer agent decomposes the goal into subtasks, selects appropriate skills, and determines which subtasks require local interaction. When a local action is needed—such as opening a browser window, filling a form, or manipulating a file—the cloud agent sends a structured command to the client side harness. The harness executes the action within the user’s environment, returns state information or results, and the cloud agent continues planning. This back and forth continues until the workflow completes, and because the cloud agent maintains persistent state, the workflow can run for hours or months without user supervision.

This hybrid model is conceptually similar to Azure’s and AWS’s cloud agents, but with a crucial difference. Azure VM Agent and AWS SSM Agent are privileged system services designed for infrastructure management, patching, telemetry, and remote command execution. Perplexity’s client harness is not a privileged agent; it is a user permissioned execution surface that allows the cloud agent to act as if it were a human user interacting with the machine. The similarity lies in the pattern: a cloud service orchestrates tasks, and a local component executes them. The difference lies in the depth of access and the security model.

How Perplexity transitions between cloud execution and local execution

To understand the transition mechanism, imagine a workflow such as booking travel. The user asks Computer to find flights, compare options, and complete the booking. The cloud agent performs the research using Perplexity’s search native intelligence and multi model orchestration. Once it identifies the desired itinerary, it needs to interact with the user’s browser or booking app. At this point, the cloud agent sends a command to the local harness: open the booking site, navigate to the correct page, fill in the traveler details, and wait for user confirmation before submitting payment. The harness executes these actions, streams back page content or DOM state, and the cloud agent continues reasoning. The workflow oscillates between cloud reasoning and local execution until the task is complete.

This pattern generalizes to any long running workflow. The cloud agent maintains the plan, memory, and schedule. The local harness provides access to the user’s environment. The two communicate through a secure channel, typically WebSocket or a similar bidirectional protocol. The cloud agent can pause, resume, retry, or escalate tasks. The local harness can request clarification or permission. The entire system behaves like a distributed agent with a cloud brain and local hands.

This architecture explains how Perplexity can run workflows for hours or months. The cloud agent persists state, monitors triggers, and schedules tasks. The local harness wakes when needed, executes actions, and returns results. The user does not need to keep the interface open; the agent continues working in the background.

Why this matters for my drone video sensing analytics system

My dvsa api application already embodies the computational core of drone analytics: ingesting video, extracting trajectories, detecting inflection signatures, computing importance sampling metrics, and producing observability outputs. What I want is the Perplexity style agentic layer: a system where users can define high level goals such as continuously analyzing flights, generating daily reports, or monitoring anomalies, and where an intelligent agent orchestrates long running workflows that span both cloud and local resources.

The Perplexity model provides a blueprint. I need a cloud hosted planner that decomposes user goals into subtasks, selects skills, and manages schedules. I need a local runner that exposes dvsa api and local compute resources to the cloud agent. I need a secure channel between the two. And I need a UX that presents this as “Your Drone Computer,” a mode where the agent can use the user’s machine to complete drone analytics tasks.

The local runner in my system would be analogous to Perplexity’s client harness. It would not be a privileged OS level agent like Azure VM Agent or AWS SSM Agent. Instead, it would be a user permissioned daemon or app that can access drone video files, run dvsa api, and return results. The cloud agent would orchestrate ingestion, analytics, reporting, and scheduling. The transition between cloud and local execution would follow the same pattern: cloud planning, local execution, cloud reasoning, and local execution.

This hybrid architecture is ideal for drone analytics because it allows us to combine cloud intelligence with local compute. Users can run dvsa api on their own GPU equipped machines while benefiting from cloud hosted planning, memory, and coordination. Long running workflows become possible: continuous ingestion of new flights, daily summaries, anomaly alerts, and scheduled reports. The agent can operate for hours or months, just like Perplexity’s Computer.

 Sample Google Apps Script to send out bulk mails:

// ── CONFIG ────────────────────────────────────────────────────────────────
const SHEET_NAME  = "Contacts";
const DAILY_LIMIT = 500;        // ← Change to 2000 if you have Google Workspace
const FROM_NAME   = "Ravi Rajamani";

// Column indices (1-based, matching your sheet layout)
const COL_EMAIL   = 1;  // Column A: to_email
const COL_SUBJECT = 7;  // Column G: subject
const COL_BODY    = 8;  // Column H: body
const COL_STATUS  = 9;  // Column I: Status

// ── MAIN FUNCTION ─────────────────────────────────────────────────────────
function sendCampaign() {
  const ss    = SpreadsheetApp.getActiveSpreadsheet();
  const sheet = ss.getSheetByName(SHEET_NAME);

  if (!sheet) {
    Logger.log('ERROR: Sheet "' + SHEET_NAME + '" not found. Check the tab name.');
    return;
  }

  const lastRow = sheet.getLastRow();
  if (lastRow < 2) {
    Logger.log("No data rows found.");
    return;
  }

  // ── READ ALL DATA IN ONE CALL (the key fix) ───────────────────────────
  // This fetches the entire sheet as a 2D array in a single API call,
  // instead of making 4 individual calls per row inside the loop.
  const numRows = lastRow - 1; // exclude header row
  const allData = sheet.getRange(2, 1, numRows, COL_STATUS).getValues();
  // allData[i] is a 0-indexed array for row (i+2) of the sheet
  // allData[i][0] = to_email, [6] = subject, [7] = body, [8] = Status

  Logger.log("Data loaded. Total rows: " + numRows);

  // ── COLLECT ROWS TO SEND ──────────────────────────────────────────────
  // Build a list of {sheetRow, email, subject, body} for unsent rows only.
  // This entire pass is pure in-memory — no Sheets API calls.
  const toSend = [];
  for (let i = 0; i < allData.length; i++) {
    const status = String(allData[i][COL_STATUS - 1]).trim();
    if (status === "Sent") continue;                          // already sent
    if (status.startsWith("Error:")) continue;               // skip permanent errors

    const email   = String(allData[i][COL_EMAIL   - 1]).trim();
    const subject = String(allData[i][COL_SUBJECT - 1]).trim();
    const body    = String(allData[i][COL_BODY    - 1]).trim();

    if (!email || !email.includes("@")) continue;            // bad address
    if (!subject || !body) continue;                         // incomplete row

    toSend.push({ sheetRow: i + 2, email, subject, body });  // sheetRow is 1-based
  }

  Logger.log("Unsent rows found: " + toSend.length);

  if (toSend.length === 0) {
    Logger.log("Campaign complete — all rows have been sent.");
    return;
  }

  // ── SEND EMAILS ───────────────────────────────────────────────────────
  // Batch status updates: collect changes, then write them all at once
  // at the end of the run (or every 50 sends as a safety checkpoint).
  let sentThisRun = 0;
  let errorCount  = 0;
  const statusUpdates = []; // {sheetRow, value}

  const limit = Math.min(DAILY_LIMIT, toSend.length);

  for (let j = 0; j < limit; j++) {
    const { sheetRow, email, subject, body } = toSend[j];

    try {
      MailApp.sendEmail({
        to:      email,
        subject: subject,
        body:    body,
        name:    FROM_NAME
      });

      statusUpdates.push({ sheetRow, value: "Sent" });
      sentThisRun++;

      if (sentThisRun % 50 === 0) {
        // Checkpoint write every 50 sends so progress isn't lost if we time out
        flushStatusUpdates(sheet, statusUpdates);
        Logger.log("Checkpoint: " + sentThisRun + " sent so far...");
      }

    } catch (e) {
      statusUpdates.push({ sheetRow, value: "Error: " + e.message });
      errorCount++;
      Logger.log("FAILED row " + sheetRow + " (" + email + "): " + e.message);
    }

    // 200ms pause to stay within Gmail's per-second rate limit
    Utilities.sleep(200);
  }

  // ── FINAL WRITE ───────────────────────────────────────────────────────
  // Write any remaining status updates not yet flushed
  flushStatusUpdates(sheet, statusUpdates);

  // ── SUMMARY ───────────────────────────────────────────────────────────
  Logger.log("─────────────────────────────────────");
  Logger.log("Run complete.");
  Logger.log("Sent this run:   " + sentThisRun);
  Logger.log("Errors this run: " + errorCount);
  Logger.log("Remaining:       " + (toSend.length - sentThisRun));
  Logger.log("─────────────────────────────────────");
}

// ── HELPER: batch-write all pending status updates ─────────────────────────
// Clears the array after writing so we don't double-write on checkpoints.
function flushStatusUpdates(sheet, updates) {
  if (updates.length === 0) return;
  for (const { sheetRow, value } of updates) {
    sheet.getRange(sheetRow, COL_STATUS).setValue(value);
  }
  SpreadsheetApp.flush(); // force Sheets to commit writes immediately
  updates.length = 0;     // clear in-place so the caller's array is emptied
}

 

The future of work is being reshaped by several big forces at the same time: faster digital change, artificial intelligence, automation, the green transition, higher living costs, slower economic growth in some places, geopolitical tensions, and major demographic shifts. These forces are not moving separately. They are overlapping, pushing businesses to change how they operate, what kinds of workers they need, what skills matter, and how people move through their careers. The overall message is not simply that technology will take jobs away, or that new jobs will automatically replace old ones. The picture is more mixed. Many jobs will grow, many will shrink, and many will change in ways that make training, redeployment, and better workforce planning much more important than before.

Digital access is one of the strongest drivers of change. As more people, businesses, and systems become connected, work becomes more digital, more data-driven, and more open to automation. Artificial intelligence and information-processing tools are expected to affect almost every sector, with generative AI making advanced technology easier for non-specialists to use. Robots and autonomous systems are also spreading, especially in manufacturing, logistics, transport, and other industries where machines can take on repeated or physically demanding tasks. At the same time, energy technologies, new materials, semiconductors, sensing technologies, quantum tools, biotechnology, and space technologies are all expected to influence parts of the economy. The biggest near-term impact, however, comes from AI, digital access, and automation because they touch so many jobs and tasks.

The labour market is expected to grow overall, but with a lot of churn. Across the jobs covered in the analysis, new job creation and job loss together are expected to affect about one fifth of current formal employment by 2030. The number of new jobs is expected to be larger than the number of jobs displaced, leaving a positive net gain. But that positive headline does not remove the difficulty of transition. Millions of people may need to move into different roles, learn new skills, or work alongside new technologies. Growth will not be evenly spread. Some workers will be in expanding fields, while others will be in jobs where demand is falling because software, AI, self-service systems, or automation can now do more of the work.

The fastest-growing jobs by percentage are mostly technology jobs. These include big data specialists, financial technology engineers, AI and machine learning specialists, software and application developers, data warehousing specialists, information security analysts, DevOps engineers, internet of things specialists, data analysts and scientists, and user experience designers. Security-related jobs are also growing because digital systems are more important and geopolitical risks are rising. Green and energy-related roles are also expanding, including renewable energy engineers, environmental engineers, sustainability specialists, electric and autonomous vehicle specialists, renewable energy technicians, and solar energy installation specialists. These roles show how the green transition is not only an environmental issue but also a labour-market issue.

In absolute numbers, many of the largest job gains are expected in everyday frontline and care roles rather than only in advanced technology roles. Farmworkers, delivery drivers, construction workers, shop salespersons, food processing workers, car and motorcycle drivers, food and beverage workers, nursing professionals, social workers, personal care aides, teachers, project managers, general operations managers, and software developers are all expected to add many jobs. This matters because the future of work is not only about coders and AI specialists. It also includes food systems, transport, building, healthcare, education, retail, and personal services. Many growing jobs are tied to basic needs, aging populations, rising demand for care, growing working-age populations in some regions, and the need to build and maintain infrastructure.

The jobs most likely to decline are concentrated in clerical, administrative, and routine information-processing work. Data entry clerks, bank tellers, postal service clerks, cashiers and ticket clerks, administrative assistants, executive secretaries, accounting and payroll clerks, material-recording clerks, telemarketers, legal secretaries, claims adjusters, and some printing-related roles are expected to shrink. These jobs are vulnerable because the tasks involved can often be standardized, digitized, automated, or shifted to self-service platforms. Some creative and professional support roles, such as graphic designers and legal secretaries, also face pressure as AI tools become better at producing drafts, images, summaries, and routine analysis. This does not mean that all human work in these areas disappears, but it does mean fewer people may be needed for the same tasks, and the remaining roles may require higher judgment, stronger client skills, or better ability to use digital tools.

An important question is not only whether machines replace people, but how people and machines work together. Today, nearly half of work tasks are still done mainly by people, with a smaller share done mainly by technology and another share done by people and technology together. By 2030, the balance is expected to be much more even. More tasks will be done by technology alone, and more will be done through human-machine collaboration. This shift can take two different paths. One path is deeper automation, where technology replaces human work. The other is augmentation, where technology helps people do more, make better decisions, work faster, or handle more complex tasks. The outcome will depend on business choices, worker training, job design, and public policy. If technology is used only to cut labour, disruption and inequality may grow. If it is used to raise human productivity and create better work, more people can share in the gains.

Technology is not the only force changing work. High living costs and economic uncertainty are pushing businesses to rethink prices, wages, productivity, staffing, and operating models. Even where inflation is easing, many households and companies still feel the pressure of higher costs. Slower growth can reduce hiring in some areas and lead firms to search for efficiency. At the same time, it can also increase demand for business development, sales, logistics, and AI-related roles that help organizations find new markets, lower costs, or improve operations. Economic pressure therefore creates both job loss and job growth, depending on whether a role is seen as a cost to reduce or a capability needed to adapt.

Geopolitical tension and fragmentation are also changing the labour market. Trade restrictions, industrial policy, subsidies, and conflict risks are leading some companies to rethink supply chains, where they locate work, and how much control they want over production. Some firms expect to reshore, nearshore, or friendshore parts of their operations, while others may still offshore where it helps them compete. These pressures raise demand for supply chain specialists, business intelligence analysts, business development professionals, strategic advisers, security managers, and cybersecurity workers. They also make resilience, leadership, flexibility, and global awareness more important because businesses need people who can operate in uncertain and divided conditions.

The green transition is another major source of change. Businesses expect investments in cutting emissions and adapting to climate change to reshape their operations. This is especially important in sectors such as energy, transport, construction, manufacturing, mining, metals, chemicals, agriculture, and infrastructure. Climate action is expected to create demand for environmental engineers, renewable energy engineers, sustainability specialists, electric vehicle specialists, energy engineers, and technicians who can install and maintain cleaner systems. It will also change existing jobs, especially in industries with high emissions or high exposure to climate risks. Workers will need green skills, but supply is not keeping up with demand. This means the green transition could create good opportunities, but only if training systems help people move into those jobs.

Demographic change is pulling labour markets in two directions. In many higher-income economies, populations are aging and the working-age population is shrinking. This creates pressure on healthcare, care services, pensions, and labour supply. It increases demand for nurses, personal care aides, social workers, healthcare managers, and workers who can support older populations. It may also push companies toward automation because there are fewer available workers. In many lower-income economies, the working-age population is growing. This can be a major advantage if enough good jobs are created, but it can also become a serious challenge if young people enter the labour market faster than economies can absorb them. Education, training, and job creation are therefore important to whether demographic change becomes an opportunity or a source of instability.

The skills picture is just as important as the jobs picture. Employers expect a large share of workers’ skills to change by 2030. The pace of disruption is slightly lower than in some earlier years, partly because more workers have already completed training and many companies have become more used to digital change. Even so, the scale is still large. If the global workforce were represented by 100 people, more than half would need some form of training by 2030. Many could be upskilled in their current jobs. Others could be trained and moved into different roles inside their organizations. But a significant group may not receive the training they need, leaving their employment prospects at risk.

Analytical thinking remains the most important core skill. Employers still need people who can understand problems, weigh evidence, and make sound decisions. But the next most important skills show that technical ability alone is not enough. Resilience, flexibility, agility, leadership, social influence, creative thinking, motivation, self-awareness, empathy, active listening, curiosity, lifelong learning, talent management, service orientation, and technological literacy all matter. The strongest future workers are likely to be those who combine human judgment with comfort using technology. The fastest-rising skills are AI and big data, networks and cybersecurity, technological literacy, creative thinking, resilience, flexibility, agility, curiosity, lifelong learning, leadership, talent management, analytical thinking, systems thinking, and environmental stewardship.

Some skills are expected to become less prevalent, especially manual dexterity, endurance, and precision where machines can take over repetitive physical tasks. Reading, writing, and mathematics remain basic and important, but some routine uses of these skills may be supported by AI. Dependability, attention to detail, and quality control remain useful, but employers expect other skills to grow faster. The difference between growing and declining jobs is especially clear in resilience, flexibility, resource management, operations, quality control, programming, technological literacy, and analytical thinking. In other words, workers moving into growing roles often need to be more adaptable, more comfortable with technology, and better able to manage complex work.

Generative AI is changing the skills debate because it can help with writing, summarizing, translating, coding, analyzing information, and producing drafts. But its limits are also important. Many skills still require physical presence, human judgment, trust, responsibility, empathy, creativity in context, and the ability to work with people. The most realistic near-term effect of AI is not full replacement across most skills, but a growing need for people to use AI well. Workers will need to know when AI is useful, when it is unreliable, how to check its output, how to ask better questions, and how to combine AI support with their own expertise. This makes AI literacy a general workplace skill, not only a specialist skill.

The biggest barrier to business transformation is the skills gap. Employers across most industries and economies say they cannot transform as quickly as they need to because workers with the right skills are hard to find. Other major barriers include organizational culture, resistance to change, outdated regulations, weak data and technical infrastructure, difficulty attracting talent to industries or firms, lack of investment capital, and weak understanding of new opportunities. This shows that the problem is not simply individual workers needing to try harder. Systems have to change too. Companies need better training and job pathways. Governments need stronger education and reskilling policies. Industries may need to cooperate because many talent shortages are shared across firms, not caused by one employer alone.

Most employers plan to respond by upskilling their current workforce. This is the most common strategy because it is often easier and more responsible to train existing workers than to replace them. Many employers also plan to automate tasks, hire people with new skills, use technology to augment workers, transition staff from declining roles into growing roles, and reduce staff where skills become less relevant. In response to AI specifically, many companies plan to train workers to work alongside AI, hire people who can design or adapt AI tools, hire people who can use AI effectively, and reorganize parts of their business around new AI-related opportunities. At the same time, a large share also expects to reduce headcount where AI can replicate human work. This means AI will be both a growth tool and a displacement risk.

Talent availability is becoming a serious concern. Fewer employers now expect hiring conditions to improve than in the past, and many expect it to become harder to find the right people. To attract and keep workers, employers are putting more attention on health and well-being, reskilling and upskilling, better promotion paths, higher wages, flexible work, better working hours, support for caregivers, safer workplaces, and broader talent pools. Skills-based hiring is gaining attention because relying too heavily on degrees can limit access to talent, especially when many growing roles can be reached through work experience, short courses, vocational training, apprenticeships, or practical assessment. Work experience remains the most common way employers judge skills, but pre-employment tests and skills assessments are becoming more important.

Employers also increasingly see broader hiring as a way to deal with talent shortages. Many have diversity, equity, and inclusion measures in place, and many plan training, targeted recruitment, pay reviews, anti-harassment policies, support for workers with caregiving responsibilities, and goals for improving representation. The practical reason is clear: when labour is scarce and skills needs are changing, businesses cannot afford to overlook qualified people. This includes women, workers with disabilities, younger workers, older workers, workers from low-income backgrounds, migrants, refugees, displaced workers, and people from groups that have been left out of opportunity. The broader point is that fairer access to work is not separate from workforce planning. It is part of how companies widen their talent base.

Wages are expected to take a larger share of revenue for many employers by 2030, mainly because companies need to retain talent and connect pay more closely to productivity and performance. Many employers also want to reduce wage inequality or protect workers’ purchasing power, although cost control still matters. The evidence also points to a wage premium for higher levels of preparation, training, and experience, meaning that workers in roles requiring more preparation generally earn more. But wage gains are not distributed equally, and there can be gaps between groups even at higher skill levels. This strengthens the case for better training access, fair pay systems, and clearer career pathways.

Public policy has a major role to play. Employers most often point to funding for reskilling and upskilling, direct provision of training, stronger public education systems, more flexible hiring practices, wage-setting flexibility, remote work rules, immigration policy, wage subsidies, transport infrastructure, pension changes, and support for caregivers. The right mix will differ by country. Aging economies may need policies that keep older workers connected to the labour market and make care work more sustainable. Younger economies may need large-scale job creation and better school-to-work transitions. Countries with high digital ambitions need stronger technology infrastructure and cybersecurity skills. Countries exposed to climate risks need green skills and transition support for workers in affected industries.

The impact of these changes differs across regions and industries. Some regions are more affected by aging populations, some by growing youth populations, some by trade tensions, some by climate risks, and some by shortages of investment or infrastructure. Europe and Eastern Asia face stronger pressure from aging and talent shortages. South-Eastern Asia and Southern Asia face major opportunities from digital growth, industrial change, and large workforces, but also need training and job creation at scale. Northern America is highly exposed to AI and climate adaptation, with strong demand for technical and cybersecurity skills. Latin America and the Caribbean are focused on digitalization, labour and social issues, and climate mitigation. The Middle East and Northern Africa face high skill disruption and stronger wage and training pressures. Sub-Saharan Africa faces a mix of labour-market growth, high need for skills, investment constraints, and the chance to build future-ready workforces if education and training improve.

Industries also face different futures. Information technology, financial services, telecommunications, insurance, and professional services are highly exposed to AI, data, and cybersecurity needs. Manufacturing, automotive, aerospace, electronics, mining, chemicals, oil and gas, energy, and utilities face strong pressure from automation, new materials, energy technologies, climate rules, and supply-chain changes. Healthcare and education will grow because of demographic change, social needs, and digital tools, but they also face culture, regulation, and talent challenges. Retail, hospitality, accommodation, food, leisure, logistics, and transport will continue to rely heavily on people while also adopting automation and digital systems. Agriculture and food systems face climate, technology, and labour pressures at the same time. Across almost every sector, the same pattern appears: routine tasks are under pressure, technical and adaptive skills are rising, and companies need better ways to move workers from shrinking tasks into expanding ones.

The main lesson is that the future of work is not fixed. The same technologies and trends can lead to very different outcomes depending on how businesses, governments, schools, and workers respond. If companies automate without investing in people, many workers will be pushed out of jobs without a clear path forward. If training remains too slow, skills gaps will block growth and leave people behind. If education systems do not adjust, young people may enter the labour market without the skills employers need. If climate policy does not include worker transition plans, green growth may be uneven and unfair. But if organizations invest in upskilling, use technology to support rather than simply replace workers, broaden access to opportunity, and build practical pathways into growing jobs, the next phase of labour-market change can create more work, better work, and more resilient economies.